Analysis of D GC

[H. S. Teoh via Digitalmars-d]

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:
[...]
> > - Support generational collection using write barriers implemented
> > through memory protection.
> 
> Super slow sadly. That being said I belive D is just fine without
> generational GC. The generational hypothesis just doesn't hold to the
> extent it holds in say Java. My hypothesis is that most performance
> minded applications already allocate temporaries using region
> allocator of sorts (or using C heap).
[...]

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.


T

-- 
What did the alien say to Schubert? "Take me to your lieder."