Comment by scratcheee | Hacker News Reader

Comment by scratcheee | Hacker News Reader

Parent Full thread

I agree with most of this, but I’m not sure about tracking the size metadata becoming a required task for the caller.

The cost of storing the size of every allocation is relatively high, at least some of the time, where it isn’t implied by the usage. Meanwhile the caching system for allocations can store it very efficiently, a block of 4KB of 8-byte allocations will contain over 500 allocations that can all share their metadata. Once they’re handed out by the allocator their shared origin is obscured, so they’d need individual tracking.

I do acknowledge that when size is inherent to the context (new or allocating for a specific struct) then maybe an allocator that doesn’t track size could allow for some clever optimisations, though I’m doubtful it could overcome the loss of shared metadata, which is so much more efficient.

The Rust allocator APIs require layout information on dealloc[0]. In the majority of cases it's a non-issue. Take Vec (like std::vector) for instance, it has pointer+length+capacity. It needs the capacity value so it knows when to realloc, so it can equivalently use it to dealloc with size information as well.

The only case I know of where this is an issue is when downsizing from Vec<T> to Box<[T]> (size optimisation for read-only arrays). Box<[T]> only stores the ptr+length, so the first step is calling shrink in order to make the capacity and length equal.

When it comes to type-erasure, it happens to work just fine. A type-erased heap pointer like Box<dyn Any> will have the size+align info stored in the static vtable. Yes it's some extra space stored, but only in the .text data and not as part of any allocations.

On this topic, I've linked a short post on allocator ideas[1] by a rust std-lib maintainer, which lists some of the other things we might add to rust's upcoming (non-global) Allocator trait

[0] https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#t... [1] https://shift.click/blog/allocator-trait-talk/

> The cost of storing the size of every allocation is relatively high

Thus it would be great if we don't push the burden to the allocator. It'll also need to store the size somewhere, adding to the cost for every allocation. Pay for only what you use.

Fortunately C++17 and C23 (free_sized) have already fixed this.

Reply on news.ycombinator.com