[EXPERIMENT] Pass buffer capacity and alignment to the allocator

[connortsui20]

Summary

Removes unconditional padding from BufferMut allocation requests while preserving requested versus preferred alignment. Local macOS measurements show System allocation/drop and growth regressions, while mimalloc results are mixed. Linux testing will follow.

Changes

Keeps the allocation base and backing layout separate from the data pointer and usable capacity, so slicing and logical alignment changes preserve the layout used for growth and deallocation. Extends the allocator tests with recorded layouts and forced moving growth, covering zeroed allocation, initialized spare capacity, sliced ownership, realignment, and empty buffers.

Correctness and validation

• A 4096-byte request with effective alignment 4096 reaches the backend as Layout { size: 4096, align: 4096 }, including zeroed allocation.
• Constructors use the aligned allocation base. Acquired storage can still have an offset, and its usable capacity excludes the allocation prefix. Geometric growth and ownership transfers can provide more capacity than originally requested.
• Growth preserves the stronger of the backing and logical alignments. Custom allocator growth uses the saved old layout and the newly returned pointer, then moves the initialized slice to the aligned base if needed. A short slice gets a fresh allocation when its new usable capacity would require a backing layout smaller than the old one, since Allocator::grow cannot shrink.
• Freezing retains the backing allocation and offset. Deallocation uses the saved allocation base and layout. The allocator contract was checked against the installed allocator-api2 0.2.21 sources.
• Preserves the compile-time ZST rejection added in fix(buffer): reject ZSTs and address allocator review comments #9807. Existing compile-fail doctests cover it.

After rebasing onto 402fd1dfbd5c876ac7a4d24da3048bd69ac830d6, 892 crate tests and 14 doctests pass. The 26 allocator integration cases include the 10 layout-routing cases that failed before the original fix. Crate and workspace Clippy pass with all targets and features.

cargo nextest run -p vortex-buffer --all-features
cargo test --doc -p vortex-buffer --all-features
cargo +nightly fmt --all
rustfmt +nightly --edition 2024 --check vortex-buffer/src/allocation.rs vortex-buffer/src/buffer_mut.rs vortex-buffer/tests/allocation.rs
cargo clippy -p vortex-buffer --all-targets --all-features
cargo clippy --all-targets --all-features -- -D warnings
git diff --check

The changed files pass formatting. The workspace formatting command also ran, but its edits to four unrelated FFI/DuckDB files were discarded. The local commit hook still flags those existing formatting differences and was bypassed for this commit.

Existing macOS benchmark results and methodology

Measured baseline: 5c8c397e2297c41b81ca4aa77b0ca02c5d73728b. Measured candidate: the pre-rebase implementation, captured in local commit 5fa15ee368c56d43ed7556e9a5d23e0a37385cde and the retained candidate patch. These measurements isolate this change at the original base. They were not rerun after rebasing onto the upstream ZST and ownership changes, so they do not measure the final rebased commit.

Both versions ran on the same Apple M4 Max with macOS 15.7.3, using Rust 1.98.0, LLVM 22.1.8, aarch64-apple-darwin, optimization level 3, 16 codegen units, no LTO, full debug information, and RUSTFLAGS='-C force-frame-pointers=yes'. The standalone harness used identical locked dependencies and explicitly registered either std::alloc::System or mimalloc::MiMalloc as the global allocator. The default buffer allocator forwards through Global, so the named backend is selected by the benchmark binary. Mimalloc used wrapper 0.1.52, libmimalloc-sys 0.1.49, and native mimalloc 3.3.2.

The matrix covered 64, 4096, and 65536 bytes at effective alignments 256 and 4096, with immediate reuse or batches of 64 live buffers. Alignment 256 used requested alignment 1 and preferred alignment 256, matching normal u8 construction. Each operation includes drop:

• allocate: construct capacity N.
• zeroed: construct N zeroed bytes.
• grow: construct capacity N, initialize N bytes, then reserve an additional 4 * max(N, 4096) bytes.
• append: construct capacity N, then append the same N-byte input eight times.

Inputs and the batch container were allocated outside timing. Runtime sizes, mutable buffer references, and initialized growth contents passed through black_box. Each case used adaptive warmup, then 11 samples of approximately 20 ms or longer, with three process runs alternating implementation order. Timings below are the median of the three process medians, in ns per complete buffer operation. No builds or correctness checks ran concurrently with these measurements.

Requested-byte totals and usable capacities came from separate instrumented runs. Totals sum requests over one buffer lifetime, not peak memory or RSS. Old capacity depends on the allocation address, so the recorded capacities can differ from the timing processes. Small percentage changes do not establish statistical significance.

4096 bytes, requested alignment 4096

Backend	Work	Live	Old ns	New ns	Change	Total requested bytes, old to new	Usable bytes, old to new
system	allocate	1	14.85	52.35	+252.5%	8192 to 4096	7168 to 4096
system	allocate	64	34.33	62.10	+80.9%	8192 to 4096	7680 to 4096
system	zeroed	1	88.67	84.64	-4.6%	8192 to 4096	7168 to 4096
system	zeroed	64	146.20	113.74	-22.2%	8192 to 4096	7680 to 4096
system	grow	1	129.79	200.27	+54.3%	32768 to 24576	20480 to 20480
system	grow	64	159.31	208.66	+31.0%	32768 to 24576	20480 to 20480
system	append	1	839.23	902.00	+7.5%	120832 to 61440	57344 to 32768
system	append	64	1512.69	1601.63	+5.9%	128000 to 61440	61440 to 32768
mimalloc	allocate	1	14.52	11.64	-19.9%	8192 to 4096	8192 to 4096
mimalloc	allocate	64	49.69	35.24	-29.1%	8192 to 4096	8192 to 4096
mimalloc	zeroed	1	85.52	47.74	-44.2%	8192 to 4096	8192 to 4096
mimalloc	zeroed	64	146.80	88.80	-39.5%	8192 to 4096	8192 to 4096
mimalloc	grow	1	117.85	111.85	-5.1%	32768 to 24576	20480 to 20480
mimalloc	grow	64	167.02	151.49	-9.3%	32768 to 24576	20480 to 20480
mimalloc	append	1	670.18	690.82	+3.1%	65536 to 61440	32768 to 32768
mimalloc	append	64	674.05	704.59	+4.5%	65536 to 61440	32768 to 32768

Initial allocation and zeroed requests change from (8192, align 1) to (4096, align 4096). Forced growth ends with 20480 usable bytes in both versions, while the final backing request falls from 24576 to 20480 bytes.

4096 bytes, normal preferred alignment 256

Backend	Work	Live	Old ns	New ns	Change	Total requested bytes, old to new	Usable bytes, old to new
system	allocate	1	14.78	18.88	+27.7%	4352 to 4096	4352 to 4096
system	allocate	64	33.98	38.13	+12.2%	4352 to 4096	4352 to 4096
system	zeroed	1	52.33	48.98	-6.4%	4352 to 4096	4352 to 4096
system	zeroed	64	96.94	89.37	-7.8%	4352 to 4096	4352 to 4096
system	grow	1	127.07	128.02	+0.7%	24833 to 24576	20480 to 20480
system	grow	64	159.88	163.39	+2.2%	24833 to 24576	20480 to 20480
system	append	1	826.05	903.72	+9.4%	65283 to 61440	34816 to 32768
system	append	64	1538.15	792.17	-48.5%	65283 to 61440	34816 to 32768
mimalloc	allocate	1	14.55	11.27	-22.5%	4352 to 4096	4352 to 4096
mimalloc	allocate	64	39.99	35.26	-11.8%	4352 to 4096	4352 to 4096
mimalloc	zeroed	1	63.44	44.31	-30.2%	4352 to 4096	4352 to 4096
mimalloc	zeroed	64	106.45	86.63	-18.6%	4352 to 4096	4352 to 4096
mimalloc	grow	1	118.13	113.42	-4.0%	24833 to 24576	20480 to 20480
mimalloc	grow	64	159.79	160.77	+0.6%	24833 to 24576	20480 to 20480
mimalloc	append	1	730.71	750.80	+2.7%	65283 to 61440	34816 to 32768
mimalloc	append	64	729.68	720.97	-1.2%	65283 to 61440	34816 to 32768

Initial allocation and zeroed requests change from (4352, align 1) to (4096, align 256). Growth retains the preferred backing alignment while continuing to report requested alignment 1.

Other regressions and context sensitivity

System immediate allocation/drop for 64 bytes at preferred alignment 256 increases from 27.60 to 70.15 ns, while the request falls from 320 to 64 bytes and recorded usable capacity falls from 160 to 64 bytes. Mimalloc increases from 8.36 to 10.56 ns for the same case, with recorded old capacity ranging from 128 to 320 bytes.

Mimalloc appending eight 64-byte chunks at alignment 4096 increases from 27.51 to 55.60 ns. The old implementation uses one 4160-byte request with 4160 usable bytes. The new implementation uses three requests totaling 832 bytes and ends at capacity 512. Losing incidental padding capacity can require more growth operations even when total requested bytes fall.

The 65536-byte, 4096-aligned System allocation/drop case is sensitive to benchmark context:

Context	Live buffers	Old ns	New ns
Full matrix	1	16.99	13473.50
Full matrix	64	572.40	379.25
Fresh process, only this workload	1	16.57	53.72
Fresh process, only this workload	64	80.73	134.51

The request falls from 69632 to 65536 bytes, with the same recorded usable capacities. Immediate reuse regresses in both contexts, while the full-matrix batch improves. The large difference suggests allocator history matters, but its internal cause was not established. The checked Rust System implementation routes these aligned requests through posix_memalign.

A separate macOS System adapter experiment recovers much of the allocation/drop cost by retaining padding inside that specific allocator. For 4096 bytes at alignment 4096, it measures 17.68 ns versus 52.35 ns for the new native System path, but requests 8192 raw bytes while exposing only 4096 usable bytes. It also worsens zeroed batches from 113.74 to 151.49 ns and normal-preferred-alignment append batches from 792.17 to 1809.26 ns. The adapter is not included in this PR, and the System regressions remain.

These measurements do not establish Linux behavior, application throughput, or resident-memory savings. The harness, raw CSVs, and reproduction bundle are retained locally rather than attached to this PR.

[codspeed-hq]

Merging this PR will degrade performance by 7.14%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 23 improved benchmarks
❌ 43 regressed benchmarks
✅ 2121 untouched benchmarks
⏩ 218 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	allocate_drop_vortex[64]	3 µs	7.6 µs	-61.2%
❌	Simulation	bitwise_and_vortex_buffer[128]	4 µs	8.7 µs	-54%
❌	Simulation	bitwise_or_vortex_buffer[128]	4.1 µs	8.8 µs	-53.32%
❌	Simulation	allocate_drop_vortex_custom[64]	3.6 µs	7.5 µs	-51.43%
❌	Simulation	bitwise_not_vortex_buffer[128]	4.7 µs	9.5 µs	-50.8%
❌	Simulation	allocate_freeze_drop_arrow[64]	3.6 µs	7.1 µs	-49.73%
❌	Simulation	bitwise_and_vortex_buffer[1024]	4.3 µs	8.4 µs	-49.15%
❌	Simulation	bitwise_and_vortex_buffer[2048]	4.7 µs	9.1 µs	-48.4%
❌	Simulation	allocate_freeze_drop_vortex_custom[64]	4.3 µs	8.3 µs	-48.03%
❌	Simulation	collect_bool_u32_gt[1024]	10.7 µs	14.2 µs	-24.95%
❌	Simulation	allocate_freeze_drop_vortex_custom[256]	6.2 µs	8.2 µs	-24.04%
❌	Simulation	allocate_freeze_drop_vortex[16384]	6 µs	7.7 µs	-21.45%
❌	Simulation	allocate_freeze_drop_vortex[65536]	6 µs	7.7 µs	-21.35%
❌	Simulation	new_raw_prim_test_between[i32, 2048]	62 µs	77.9 µs	-20.44%
❌	Simulation	allocate_drop_arrow[0]	456.9 ns	568 ns	-19.56%
❌	Simulation	allocate_freeze_drop_vortex[64]	3.5 µs	4.3 µs	-18.85%
❌	Simulation	random_i16[0.8]	74.6 µs	91.4 µs	-18.35%
❌	Simulation	allocate_drop_vortex[65536]	6.4 µs	7.9 µs	-18.02%
❌	Simulation	preverify_advancing_ptr_unchecked[1000]	11.5 µs	13.9 µs	-17.71%
❌	Simulation	allocate_drop_vortex[16384]	6.4 µs	7.8 µs	-16.98%
...	...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ct/buffer-allocation-boundary (22ef33a) with develop (402fd1d)}

Footnotes

1. 218 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[connortsui20]

Linux x86_64 reproduces the main System allocation and growth regressions. Mimalloc results are mixed, and removing padding makes small aligned appends slower with both allocators.

Compared baseline 402fd1dfbd5c876ac7a4d24da3048bd69ac830d6 against candidate 22ef33addffb67753c46e70b47f267871473ea28 on a Ryzen 9 7950X with Linux/glibc. This isolates the final rebased PR. The macOS results used an earlier base and pre-rebase candidate, so the percentages are not a controlled comparison of operating systems or architectures.

These selected cases use alignment 4096 and one live buffer. Times include drop and are the median of three process medians. Positive changes mean slower.

Allocator	Operation	Before ns	After ns	Change
system	Allocate 4 KiB	24.63	36.81	+49.4%
system	Grow 4 KiB	108.91	136.42	+25.3%
system	Append eight 64-byte chunks	48.26	109.99	+127.9%
mimalloc	Allocate 4 KiB	37.65	31.26	-17.0%
mimalloc	Zeroed 4 KiB	93.57	58.62	-37.4%
mimalloc	Append eight 64-byte chunks	49.67	108.67	+118.8%

Separate instrumentation confirms the padding tradeoff: appending eight 64-byte chunks at alignment 4096 changes from one allocation to three with both allocators, while total requested bytes fall from 4160 to 832. Old usable capacity depends on the allocation address, so these counts describe the instrumented runs.

The large macOS 64 KiB allocation spike did not reproduce. Linux System allocation/drop at alignment 4096 measured 24.39 to 37.04 ns in the full matrix and 25.12 to 39.27 ns in fresh processes. The regression persists, but without the roughly 13,473 ns macOS result.

Other differences worth retaining:

• System allocation/drop for 64 bytes at preferred alignment 256 regressed by 8–10%, much less than on macOS. Mimalloc regressed by 26–31%.
• Zeroing batches of 64 live 64 KiB buffers at preferred alignment 256 regressed by 38.5% in isolation, from 11.94 to 16.53 µs per buffer.
• Appending eight 64 KiB chunks at alignment 4096 improved by 36.4% with System in isolation, from 229.78 to 146.23 µs.
• System growth from 4 KiB at preferred alignment 256 was less stable: candidate process medians ranged from 136 to 193 ns, versus 105 to 109 ns before. All three runs regressed, but the precise percentage varied.

The installed Rust System implementation routes the old alignment-1 requests through malloc and the new alignment-256/4096 requests through posix_memalign. Zeroed allocation changes from calloc to aligned allocation followed by zeroing. The libc internals behind the larger-buffer results were not profiled.

Benchmark methodology and validation

• Environment: AMD Ryzen 9 7950X, Linux 7.2.3-1-cachyos, glibc 2.44, Rust 1.98.0, LLVM 22.1.8, x86_64-unknown-linux-gnu.
• Mimalloc: wrapper 0.1.52, libmimalloc-sys 0.1.49, native mimalloc 3.3.2.
• The standalone harness recreates the matrix described in the PR and uses the real vortex-buffer crate from each revision. The original macOS harness was not attached.
• Identical locked dependencies, optimization level 3, 16 codegen units, no LTO, full debug information, and RUSTFLAGS="-C force-frame-pointers=yes". Each binary explicitly selects System or MiMalloc as its global allocator.
• Sizes: 64, 4096, and 65536 bytes. Effective alignments: 256 and 4096. Alignment 256 means requested alignment 1 and preferred alignment 256.
• Allocate constructs capacity N. Zeroed constructs N zeroed bytes. Grow initializes N bytes then reserves an additional 4 * max(N, 4096) bytes. Append appends the same N-byte input eight times.
• One or 64 buffers remain live before drop. Inputs and the batch vector are allocated outside timing. Timings include batch-vector bookkeeping.
• Runtime sizes, alignments, input slices, mutable buffers, and initialized growth contents pass through black_box.
• Adaptive warmup doubles the iteration count until a batch takes at least 25 ms, followed by 11 samples at that iteration count. Three process runs per version alternate old/new order. Reported changes are ratios of the displayed medians.
• Runs execute serially, pinned to CPU 2, with no concurrent builds, tests, or other benchmark runs. The powersave governor and CPU boost remained enabled. No allocator environment overrides were set.
• The full matrix has 96 cases per revision and 6336 samples overall. Ten isolated cases add 660 samples, each run alone in fresh processes with the same protocol.
• Instrumentation uses separate binaries, so counters do not affect timings. Requested bytes are sums of backend requests over a buffer lifetime, not peak memory or RSS.
• Release builds, harness formatting, default and all-feature Clippy checks, and content/length/requested-alignment assertions passed. The 192 instrumented cases cover both revisions and both allocators.

No repository code changed. Workspace tests were not rerun. These measurements do not establish application throughput, multithreaded behavior, RSS savings, or results on Intel, musl, or 32-bit x86. Small percentage changes need more evidence before treating them as regressions. The harness and raw samples are retained locally.

Full Linux matrix, ns per operation

Allocator	Work	Bytes	Alignment	Live	Before ns	After ns	Change
system	Allocate	64	256	1	21.21	23.42	+10.4%
system	Allocate	64	256	64	25.55	32.21	+26.1%
system	Zeroed	64	256	1	26.98	25.07	-7.1%
system	Zeroed	64	256	64	31.37	33.55	+6.9%
system	Grow	64	256	1	43.07	55.82	+29.6%
system	Grow	64	256	64	1034.98	1147.06	+10.8%
system	Append	64	256	1	71.78	71.81	+0.0%
system	Append	64	256	64	74.93	86.96	+16.1%
system	Allocate	64	4096	1	36.52	23.59	-35.4%
system	Allocate	64	4096	64	589.01	596.37	+1.3%
system	Zeroed	64	4096	1	68.18	25.23	-63.0%
system	Zeroed	64	4096	64	630.91	599.07	-5.0%
system	Grow	64	4096	1	57.04	55.96	-1.9%
system	Grow	64	4096	64	1972.68	2050.78	+4.0%
system	Append	64	4096	1	48.26	109.99	+127.9%
system	Append	64	4096	64	761.25	702.61	-7.7%
system	Allocate	4096	256	1	24.72	36.68	+48.4%
system	Allocate	4096	256	64	604.52	625.98	+3.6%
system	Zeroed	4096	256	1	60.07	64.86	+8.0%
system	Zeroed	4096	256	64	675.63	688.64	+1.9%
system	Grow	4096	256	1	105.37	157.91	+49.9%
system	Grow	4096	256	64	2199.98	2224.23	+1.1%
system	Append	4096	256	1	806.75	863.41	+7.0%
system	Append	4096	256	64	9345.88	9194.48	-1.6%
system	Allocate	4096	4096	1	24.63	36.81	+49.4%
system	Allocate	4096	4096	64	834.98	884.47	+5.9%
system	Zeroed	4096	4096	1	89.20	64.48	-27.7%
system	Zeroed	4096	4096	64	1644.06	1678.88	+2.1%
system	Grow	4096	4096	1	108.91	136.42	+25.3%
system	Grow	4096	4096	64	2148.42	2274.60	+5.9%
system	Append	4096	4096	1	815.47	780.69	-4.3%
system	Append	4096	4096	64	10113.32	10002.44	-1.1%
system	Allocate	65536	256	1	24.52	35.99	+46.8%
system	Allocate	65536	256	64	1283.85	1352.30	+5.3%
system	Zeroed	65536	256	1	515.71	528.32	+2.4%
system	Zeroed	65536	256	64	11854.39	16524.59	+39.4%
system	Grow	65536	256	1	1990.10	1941.09	-2.5%
system	Grow	65536	256	64	21107.93	20144.46	-4.6%
system	Append	65536	256	1	249614.41	251143.41	+0.6%
system	Append	65536	256	64	161934.35	161929.06	-0.0%
system	Allocate	65536	4096	1	24.39	37.04	+51.8%
system	Allocate	65536	4096	64	1446.46	1497.30	+3.5%
system	Zeroed	65536	4096	1	544.52	526.45	-3.3%
system	Zeroed	65536	4096	64	17519.02	17568.93	+0.3%
system	Grow	65536	4096	1	1820.20	1886.31	+3.6%
system	Grow	65536	4096	64	19528.13	19628.86	+0.5%
system	Append	65536	4096	1	232341.78	145803.13	-37.2%
system	Append	65536	4096	64	158731.15	159303.55	+0.4%
mimalloc	Allocate	64	256	1	24.36	31.96	+31.2%
mimalloc	Allocate	64	256	64	19.58	23.12	+18.1%
mimalloc	Zeroed	64	256	1	26.01	31.53	+21.2%
mimalloc	Zeroed	64	256	64	23.51	26.98	+14.8%
mimalloc	Grow	64	256	1	48.71	58.50	+20.1%
mimalloc	Grow	64	256	64	57.99	64.95	+12.0%
mimalloc	Append	64	256	1	67.01	79.87	+19.2%
mimalloc	Append	64	256	64	62.01	69.73	+12.5%
mimalloc	Allocate	64	4096	1	36.31	32.19	-11.3%
mimalloc	Allocate	64	4096	64	50.92	50.85	-0.1%
mimalloc	Zeroed	64	4096	1	71.04	71.19	+0.2%
mimalloc	Zeroed	64	4096	64	91.48	90.64	-0.9%
mimalloc	Grow	64	4096	1	62.81	65.64	+4.5%
mimalloc	Grow	64	4096	64	74.45	69.56	-6.6%
mimalloc	Append	64	4096	1	49.67	108.67	+118.8%
mimalloc	Append	64	4096	64	70.79	126.08	+78.1%
mimalloc	Allocate	4096	256	1	34.30	32.16	-6.2%
mimalloc	Allocate	4096	256	64	51.01	45.69	-10.4%
mimalloc	Zeroed	4096	256	1	71.30	58.57	-17.9%
mimalloc	Zeroed	4096	256	64	90.87	78.43	-13.7%
mimalloc	Grow	4096	256	1	125.89	117.42	-6.7%
mimalloc	Grow	4096	256	64	139.54	137.78	-1.3%
mimalloc	Append	4096	256	1	721.50	710.27	-1.6%
mimalloc	Append	4096	256	64	838.23	823.12	-1.8%
mimalloc	Allocate	4096	4096	1	37.65	31.26	-17.0%
mimalloc	Allocate	4096	4096	64	59.01	46.14	-21.8%
mimalloc	Zeroed	4096	4096	1	93.57	58.62	-37.4%
mimalloc	Zeroed	4096	4096	64	124.11	78.96	-36.4%
mimalloc	Grow	4096	4096	1	122.38	116.75	-4.6%
mimalloc	Grow	4096	4096	64	143.02	130.28	-8.9%
mimalloc	Append	4096	4096	1	639.13	710.59	+11.2%
mimalloc	Append	4096	4096	64	766.66	821.20	+7.1%
mimalloc	Allocate	65536	256	1	35.76	36.01	+0.7%
mimalloc	Allocate	65536	256	64	72.21	69.50	-3.8%
mimalloc	Zeroed	65536	256	1	647.61	647.82	+0.0%
mimalloc	Zeroed	65536	256	64	905.09	867.61	-4.1%
mimalloc	Grow	65536	256	1	2009.54	2008.92	-0.0%
mimalloc	Grow	65536	256	64	2291.62	2288.78	-0.1%
mimalloc	Append	65536	256	1	16297.26	16353.52	+0.3%
mimalloc	Append	65536	256	64	20834.26	20643.94	-0.9%
mimalloc	Allocate	65536	4096	1	36.37	32.17	-11.5%
mimalloc	Allocate	65536	4096	64	70.14	61.14	-12.8%
mimalloc	Zeroed	65536	4096	1	647.55	531.16	-18.0%
mimalloc	Zeroed	65536	4096	64	841.83	689.32	-18.1%
mimalloc	Grow	65536	4096	1	2012.48	1993.93	-0.9%
mimalloc	Grow	65536	4096	64	2298.20	2317.84	+0.9%
mimalloc	Append	65536	4096	1	16303.80	15554.93	-4.6%
mimalloc	Append	65536	4096	64	20772.76	20895.20	+0.6%

Fresh-process checks, ns per operation

Allocator	Work/bytes/alignment/live	Before ns	After ns	Change	Before process range	After process range
system	Allocate/65536/4096/1	25.12	39.27	+56.4%	25.07 to 27.61	39.22 to 39.47
system	Allocate/65536/4096/64	1458.48	1508.74	+3.4%	1450.26 to 1458.49	1504.56 to 1509.81
system	Allocate/4096/4096/1	23.95	36.84	+53.8%	23.94 to 23.99	36.78 to 49.20
system	Grow/4096/4096/1	104.33	132.37	+26.9%	102.28 to 111.73	130.02 to 133.46
system	Allocate/64/256/1	21.16	22.95	+8.5%	21.15 to 21.17	22.87 to 23.38
mimalloc	Allocate/4096/4096/1	36.01	32.23	-10.5%	35.89 to 36.24	32.16 to 32.67
mimalloc	Append/64/4096/1	54.84	102.47	+86.9%	54.81 to 63.14	102.14 to 113.00
mimalloc	Allocate/64/256/1	24.39	30.76	+26.1%	24.35 to 24.72	30.63 to 32.34
system	Zeroed/65536/256/64	11936.03	16528.14	+38.5%	11934.14 to 12314.85	16497.22 to 16545.90
system	Append/65536/4096/1	229782.90	146229.77	-36.4%	228943.03 to 229899.77	145754.38 to 147590.54