std.allocator issues

[Andrei Alexandrescu via Digitalmars-d]

On 02/20/2016 12:39 AM, Steven Schveighoffer wrote:
> Given that there is "goodAllocSize", this seems reasonable. But for
> ease-of-use (and code efficiency), it may be more straightforward to
> allow returning more data than requested (perhaps through another
> interface function? allocateAtLeast?) and then wrap that with the other
> allocation functions that simply slice the result down to size.

Actually I confess that was the exact design for a while, and I, too, 
found it ingenious. You ask me for 100 bytes but I'll allocate 256 
anyway, why not I just return you the whole 256? But then that puts 
burden everywhere. Does the user need to remember 256 so they can pass 
me the whole buffer for freeing? That's bad for the user. Does the 
allocator accept 100, 256, or any size in between? That complicates the 
specification.

Then consider things like cast(T[]) a.allocate(T.sizeof * n). Folks 
would legitimately expect to then have an array of just n objects. If 
not, they end up with more than they asked for, or a misalignment exception.

It's simpler with what we have: you ask me for n bytes, I give you n 
bytes. You give me n bytes back to free.

> In the GC, expanding is done a page at a time. If I request an expansion
> of 1 byte, that's 4095 wasted bytes. I don't expect goodAllocSize to
> help me here.

If you call goodAllocSize(n + 1) you should get the right thing. Then 
you can pass it to the call to expand().

> BTW, just pushed an update to my i/o library that uses allocators
> exclusively for buffers. But I make the default a custom GC allocator
> that has the properties I need. I'm hoping there will be a way to get
> the desired behavior from the phobos version at some point.

Sounds great. Did you measure performance?


Andrei