Analysis of D GC

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 20 June 2017 at 16:49:44 UTC, H. S. Teoh wrote:
> On Tue, Jun 20, 2017 at 07:47:13AM +0000, Dmitry Olshansky via 
> Digitalmars-d wrote:
>> On Monday, 19 June 2017 at 23:52:16 UTC, Vladimir Panteleev 
>> wrote:
> [...]
>
>
> FWIW, here's a data point to the contrary:
>
> One of my projects involves constructing a (very large) AA that 
> grows over time, and entries are never deleted.  The AA itself 
> is persistent and lasts until the end of the program.  Besides 
> the AA, there are a couple of arrays that also grow (more 
> slowly) but eventually become unreferenced.  Because of the 
> sheer size of the AA, I've observed that GC collection cycles 
> become slower and slower, yet most of this extra work is 
> completely needless, because the only thing that might need 
> collecting is the arrays, yet the GC has to mark the entire AA 
> each time, only to discover it's still live.
>
> After some experimentation I discovered that I could get up to 
> 40-50% performance improvement just by calling GC.disable and 
> scheduling my own GC collection cycles via GC.collect at a 
> slower rate than the current default setting.
>
>>From this, it would seem to me that a generational collector 
>>would have
> helped, since most of the AA will eventually migrate to older 
> generations and most of the time the GC won't bother 
> marking/scanning those parts.  Of course, this is only for this 
> particular program, and I can't say that this is typical usage 
> for D programs in general.  But I think D would still benefit 
> from a generational collector.
>

Interestingly the moment you "reallocate" to expand the AA it 
will be considered a new object. Overall I think your case is 
more about faulty collection heuristics, that is collecting when 
there is a slim chance of getting enough of free space after 
collection.

>
> T