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.
