On Tuesday, 8 January 2013 at 02:06:02 UTC, Brad Roberts wrote:
There's some issues that can rightfully be termed "caused by
the GC", but
most of the performance issues are probably better labled
"agregious use
of short lived allocations", which cost performance regardless
of how
memory is managed. The key difference being that in manual
management the
impact is spread out and in periodic garbage collection it's
batched up.
My primary point being, blaming the GC when it's the
application style
that generates enough garbage to result in wanting to blame the
GC for the
performance cost is misplaced blame.
My 2 cents,
Brad
There's more to it than just jerkiness caused by batching. The GC
will do collection runs at inappropriate times, and that can
cause slow downs well in excess of an otherwise identical
application with manual memory management. For example, I've seen
3x performance penalty caused by the GC doing collection runs at
the wrong times. The fix required manually disabling the GC
during certain points and re-enabling afterwards.
The 2 or 3 lines of extra code I inserted to fix the 3x
performance penalty was a lot easier than performing full manual
management, but it means that you cannot sit back and expect the
GC to always do the right thing.
--rt
