Optimization fun

[H. S. Teoh via Digitalmars-d]

On Fri, Nov 07, 2014 at 10:01:41AM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
> OK, I did a little test where I would disable the GC at the beginning of
> the program, then trigger a collection every 250,000 iterations. As a
> rough visual aid, I print a message before and after the collection so
> that I can gauge how long each collection is taking. It appears that as
> the program progresses, collections become longer -- expected, because
> the hash table is growing rapidly, so the marking phase probably would
> take longer (I didn't measure this in detail though).
> 
> Overall, a puzzle that took ~7.0 seconds to solve now takes ~7.6
> seconds, which is about 8% performance degradation. That's pretty high,
> considering that we already know that most of the new allocations
> between collections is live.
[...]

P.S. Note, however, that with the GC fully enabled, the average running
time is about 9.8 seconds (the 7.0s figure is when the GC is completely
disabled and no collections are run, so memory is leaking). That's still
a ~25% improvement over the normal GC behaviour, while preventing memory
leaks, even if 8% is a little high for a scenario where we already know
most of the memory is still live. (One could see an argument for a
generational collector here!)

So arguably, the frequency of the GC's collections could be tweaked, as
Steven mentioned. We could be getting ~25% performance improvement for
free! (But this is of course highly dependent on system-specific and
program-specific measurements, so I don't know if this will actually
improve performance in general. Still, it's an interesting area to
explore in terms of improving the performance of the current GC. Where's
Andrei with his nice shiny yet-to-be-materialized new GC when we need
him??! :-P)


T

-- 
"640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.