Sneak preview into std.allocator's porcelain

[Vladimir Panteleev via Digitalmars-d]

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

I don't know enough about TLS to argue but it strikes me as odd 
that it would be slower than the layers of un-inlinable extern(C) 
calls, going through lifetime.d, gc.d, gcx.d, there locking on a 
global mutex, and allocating memory accordingly to a 
general-purpose GC (vs. specialized allocator).