Sneak preview into std.allocator's porcelain

[Andrei Alexandrescu via Digitalmars-d]

On 5/8/15 12:13 PM, Vladimir Panteleev wrote:
> On Friday, 8 May 2015 at 19:04:20 UTC, deadalnix wrote:
>> On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote:
>>> Oh I see. That will be operational once we get the built-in
>>> allocating expressions (new, array literals, delegates...) to use
>>> theAllocator. Cool, thanks, -- Andrei
>>
>> I'm not sure how desirable this is. This require a round trip to TLS +
>> virtual function call. That can be expensive, but even worse, will
>> make the optimizer blind.
>
> It will still be no worse than the current situation (GC invocation).
> Performance-sensitive algorithms can use an allocator (which won't be
> wrapped in a class) that in turn allocates memory in bulk from
> theAllocator. This pattern will allow you to discard all scratch memory
> at once once you're done with it.

That's right. That reminds me I need to implement a sort of a pool 
allocator that remembers all allocations that went through it, and 
release them all in the destructor.

What's a good name for that? I thought MarkSweepAllocator is it, but 
that term is more often used in conjunction with garbage collection.


Andrei