The purpose of D (GC rant, long)

Sean Kelly sean at f4.ca
Sat Oct 28 12:11:08 PDT 2006


Dave wrote:
> 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)

Oops!  Dunno how I missed that.

> 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?

I'm not sure of the ideal approach for Phobos, but in Ares I have 
separate malloc and calloc methods exposed.  So I'll likely just change 
calloc to initialize the entire block instead of just the allocated 
portion, and remove the spare space initializer from mallocNoSync.


Sean



More information about the Digitalmars-d mailing list