feat: optimize XNode memory layout and refactor XEntry type resolution

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.

[fslongjin]

Summary

• Slab-friendly XNode memory layout (optional): Adds a slab-friendly feature. When enabled, XNode's slots field is heap-allocated via Box<[XEntry; 64]> instead of inline. This changes the allocation footprint seen by slab-style allocators: the original ~544B node may round up to a 1K size class; with the feature, the node header and the slot array can fit smaller classes (e.g. ~64B + 512B), potentially reducing internal fragmentation in slab-heavy environments. Note: Under a default/general-purpose allocator, benchmarks in this repo do not show a net speedup; the feature is an allocator-dependent trade-off and can be beneficial in some setups (e.g. custom slab allocators).
• Pin smallvec to 1.13.1 for reproducible builds.
• Refactor XEntry::ty(): Replace chained not()/then() with a clear if/else for readability.
• Debuggability: Add a descriptive panic message for invalid XEntry tags.
• Cleanup: Remove unused Not import from core::ops.
• Benchmarks: Add benches/xarray_bench.rs for cargo bench (store/load cursor, random load, range iteration, COW clone+overwrite). Run with --features std and optionally --features "std slab-friendly" to compare.

Usage

Enable the feature in Cargo.toml if you want the slab-friendly layout:

[dependencies]
xarray = { version = "...", features = ["slab-friendly"] }

Run benchmarks:

cargo bench --features std --bench xarray_bench
cargo bench --features "std slab-friendly" --bench xarray_bench

[tatetian]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

[fslongjin]

Thanks for trying to contribute.

• reducing the effective allocation size from the previous 544-byte (which rounds up to 1K in slab allocators) to a slab-friendly 576 bytes.

Reduce from 544B to 576B?

• This also improves cache performance due to better cacheline alignment.

How exactly is the cache performance improved?

This optimization introduced this PR has no empirical result to back up. So I am not convinced that this slab-friendly feature leads to a net positive result. And if this change is a net positive, why gated by a feature? It should simply replace the current implementation.

In addition, from the PR description, it seems that this PR should be broken into several atomic commits.

Lastly, I am not sure that we want to main this crate anymore. This crate is not updated for quite some time. The latest implementation of Xarray has been moved into the Asterinas mono repo for better integration with RCU.

I apologize — the previous commit message incorrectly described the performance impact of the slab-friendly change. It should not have claimed that the optimization improves benchmark performance in general; the trade-off is allocator- and workload-dependent. I have amended the commit and updated the PR description accordingly.

Thanks for the careful review. Let me address the two concerns separately.

1) "Reduce from 544B to 576B?"

You are right that the wording is confusing if interpreted as raw struct size only.

What I intended is effective allocation footprint under slab allocators, not only size_of::<XNode>():

• In the original layout, XNode contains inline slots, so one node object is ~544B.
• In many slab allocators with coarse size classes (e.g. power-of-two), a 544B object may be placed in a 1KiB class.
• With slab-friendly, we split node metadata and slots:
  • node header (small object, typically one small slab class),
  • slot array (Box<[XEntry; 64]>, 512B class).
• So the allocator-visible total can become closer to small-class + 512B (for example ~64B + 512B = ~576B), which reduces internal fragmentation versus a single 1KiB class allocation.

So the key claim is about allocator class fit and internal fragmentation, not that a single Rust object shrinks from 544 to 576.

2) "Where is the empirical evidence?"

I ran cargo bench in this branch with the same benchmark suite under two feature sets:

• --features std
• --features "std slab-friendly"

Environment: local Linux machine(ubuntu 24.04, i5-12450H), default allocator, same code, same benchmark target (benches/xarray_bench.rs).

Benchmark	std (ns/iter)	std+slab-friendly (ns/iter)	Delta
bench_store_dense	8,517,270.35	8,717,937.25	+2.36%
bench_cursor_load_dense	603,782.84	638,052.65	+5.68%
bench_load_random_dense	3,843,162.60	4,415,553.70	+14.89%
bench_range_sparse_even	1,420,373.75	1,489,634.25	+4.88%
bench_cow_clone_then_overwrite	4,475,489.25	4,472,778.65	-0.06%

I apologize — the earlier “slight performance improvement” claim was based on measurements under DragonOS’s memory allocator. Thank you for pointing out the lack of empirical evidence. I have added the benchmark suite above; on Rust’s default allocator the numbers do show a performance regression for slab-friendly in these tests.

I have also removed that claim from the PR description and commit message.