Sneak preview into std.allocator's porcelain

[deadalnix via Digitalmars-d]

On Friday, 8 May 2015 at 19:13:21 UTC, 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.

It IS worse. Current GC to not do a round trip to TLS (which IS 
slow, especially when dynamic linking is involved) and the 
optimizer can understand the API and optimize based on it (LDC 
does it to some extent).