manual memory management

[Rob T]

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