Buffer Allocator Abstraction

[gatesn]

Initial PR to move towards a session-defined buffer allocation.

1. Sets up a MemorySession (we could move this and all buffer handle types to vortex-io and treat the i/o crate as engine integration?)
2. Defines an allocator trait, returning a WritableHostBuffer
3. Freeze the WriteableHostBuffer into a host ByteBuffer

For now, we keep the existing behavior for device buffers (i.e. vortex-cuda constructs its own device BufferHandle inside its segment source).

This change configures host VortexReadAt sources (ObjectStoreReadAt and FileReadAt) to use the allocator from the session. It also demonstrates using the allocator from within an array (chunked canonical), although it doesn't do the plumbing work all the way into the array builders.

A follow up PR will implement a pooling allocator.

Further PRs wlll port over the execution logic to use the allocator from the ExecutionCtx, eventually using clippy to forbid direct ByteBufferMut access from within our (non allocator) crates.

[0ax1]

Can this get a little RFC upfront?

[joseph-isaacs]

Why does an allocator return WritableHostBuffer vs a buffer handle?

[gatesn]

Why does an allocator return WritableHostBuffer vs a buffer handle?

BufferHandle isn't writeable

[gatesn]

@0ax1 https://github.com/vortex-data/rfcs/pull/44/changes

[codspeed-hq]

Merging this PR will degrade performance by 17.13%

⚡ 26 improved benchmarks
❌ 1 regressed benchmark
✅ 1095 untouched benchmarks
⏩ 1530 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	chunked_bool_canonical_into[(1000, 10)]	49.7 µs	60 µs	-17.13%
⚡	Simulation	take_search[(0.005, 0.05)]	168.2 µs	131.7 µs	+27.73%
⚡	Simulation	take_search[(0.005, 0.1)]	320.1 µs	247.2 µs	+29.5%
⚡	Simulation	take_search[(0.005, 0.5)]	1.5 ms	1.2 ms	+31.02%
⚡	Simulation	take_search[(0.01, 0.05)]	179.2 µs	142.7 µs	+25.58%
⚡	Simulation	take_search[(0.005, 1.0)]	3.1 ms	2.3 ms	+31.25%
⚡	Simulation	take_search[(0.01, 0.5)]	1.6 ms	1.3 ms	+28.56%
⚡	Simulation	take_search[(0.01, 1.0)]	3.3 ms	2.5 ms	+28.77%
⚡	Simulation	take_search[(0.01, 0.1)]	340.9 µs	267.9 µs	+27.22%
⚡	Simulation	take_search[(0.1, 0.05)]	249 µs	212.5 µs	+17.19%
⚡	Simulation	take_search[(0.1, 0.1)]	459.5 µs	386.6 µs	+18.87%
⚡	Simulation	take_search[(0.1, 1.0)]	4.3 ms	3.5 ms	+20.63%
⚡	Simulation	take_search[(0.1, 0.5)]	2.2 ms	1.8 ms	+20.39%
⚡	Simulation	take_search_chunked[(0.005, 0.1)]	376.6 µs	314.6 µs	+19.7%
⚡	Simulation	take_search_chunked[(0.1, 0.05)]	275.8 µs	244.8 µs	+12.67%
⚡	Simulation	take_search_chunked[(0.005, 0.05)]	197 µs	165.9 µs	+18.71%
⚡	Simulation	take_search_chunked[(0.005, 1.0)]	3.6 ms	3 ms	+20.65%
⚡	Simulation	take_search_chunked[(0.01, 1.0)]	3.9 ms	3.2 ms	+19.13%
⚡	Simulation	take_search_chunked[(0.01, 0.05)]	209.9 µs	178.9 µs	+17.34%
⚡	Simulation	take_search_chunked[(0.005, 0.5)]	1.8 ms	1.5 ms	+20.53%
...	...	...	...	...	...

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

---

_{Comparing ngates/buffer-pool (4e56156) with develop (ff21366)}

Footnotes

1. 1530 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. ↩