GC performance: collection frequency

[H. S. Teoh via Digitalmars-d]

Over in the d.learn forum, somebody posted a question about poor
performance in a text-parsing program. After a bit of profiling I
discovered that reducing GC collection frequency (i.e., GC.disable()
then manually call GC.collect() at some interval) improved program
performance by about 20%.

This isn't the first time I encountered this.  Some time ago (late last
year IIRC) I found that in one of my own CPU-intensive programs,
manually scheduling GC collection cycles won me about 30-40% performance
improvement.

While two data points is hardly statistically significant, these two do
seem to suggest that perhaps part of the GC's perceived poor performance
may stem from an overly-zealous collection schedule.

Since asking users to implement their own GC collection schedule can be
a bit onerous (not to mention greatly uglifying user code), would it be
a good idea to make the GC collection schedule configurable?  At least
that way, people can just call GC.collectSchedule(/*some value*/) as a
first stab at improving overall performance, without needing to rewrite
a whole bunch of code to avoid the GC, or go all-out @nogc.

We could also reduce the default collection frequency, of course, but
lacking sufficient data I wouldn't know what value to set it to.


T

-- 
Computers shouldn't beep through the keyhole.