GC performance: collection frequency

[Jonathan M Davis via Digitalmars-d]

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