On Monday, 14 September 2015 at 18:51:36 UTC, H. S. Teoh wrote:
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.
Isn't there some amount of configuration that can currently be
done via environment variables? Or was that just something that
someone had done in one of the GC-related dconf talks that never
made it into druntime proper? It definitely seemed like a good
idea in any case.
- Jonathan M Davis
