The purpose of D (GC rant, long)

[Dave]

Sean Kelly wrote:
> Dave wrote:
>> Sean Kelly wrote:
>>> Dave wrote:
>>>> Sean Kelly wrote:
>>>>> Now that memory is not freed when string.length is set to zero it's 
>>>>> quite possible to avoid most reallocations simply by preallocating 
>>>>> in buffers before using them (ie. set length to some large number 
>>>>> and then 
>>>>
>>>> I did not know that had been changed.. Is that now part of the 
>>>> language 'spec' somewhere as well?
>>>
>>> No.  It was implemented in 170-172 by request from Derek.  I don't 
>>> know the issue number offhand.
>>>
>>>> I'm betting this has been discussed or at least proposed, but here 
>>>> goes again; let's get an array.reserve at least for native arrays 
>>>> (that could be implemented as {arr.length = nnn; arr.length = 0;}). 
>>>> That way it would make for less of a hack than re/setting the 
>>>> length, and also codify it as part of the language.
>>>
>>> I agree that this would be useful.  Though it would probably be more 
>>> like:
>>>
>>> size_t tmp = arr.length; arr.length = nnn; arr.length = tmp;
>>>
>>
>> Oops, you're right..
>>
>> I was curious as to how much initialization cost. I took the code 
>> (bottom) and ran it three times: 1) as-is, 2) with the initialization 
>> code in gc._d_newarrayi() commented out and 3) with the initialization 
>> code in gcx._malloc() also commented out (along with (2))
> ...
>> One thing I noticed is that for most/all of the _d_new* functions, 
>> initialization will be done twice, once in the gcx.malloc and again in 
>> the _d_new* function. I believe the extra initialization could be 
>> removed in most cases (perhaps with an optional parameter to 
>> gcx.malloc()?). Maybe also some syntax to support 'void' initializers 
>> for heap allocated arrays?
> 
> What initialization in gcx.malloc?  The only call to memset I see has a 
> debug flag.  And I believe void initializers already work for arrays.
> 

Line 296:  foreach(inout byte b; cast(byte[])(p + size)[0..binsize[bin] - size]) { b = 0; }

Right above the debug (MEMSTOMP)

Not really 'initialization' as it just clears the unused portion of the 'bin', but it's still 
overhead that std.c.stdlib.malloc() doesn't have.

The important point is that currently the initialization/clearing in itself takes longer than 
stdlib.malloc, so no matter how fast the allocator is, initialization will be a bottleneck.

Any ideas on how to optimize that?

> 
> Sean