Linked by Thom Holwerda on Thu 6th Sep 2012 21:32 UTC, submitted by MOS6510
Permalink for comment 534191
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2011-05-19
Well, for ephemeral objects, then generational GC will speed up both allocation *and* deallocation. If it dies during its first collection, then there is zero overhead from the garbage collector.
It's actually the objects that survive a collection that incur the GC overhead, as they must be copied into the older generation.
There's a puzzling statement in the blog post that suggests the student may not have fully internalized this very counterintuitive fact:
But with a generational GC, it should not leak memory, and it should also not perform that badly. The temp strings should be ephemeral, and should die with no overhead. In other words, this is precisely the scenario that should perform faster with a GC than without a GC.
No wonder he ran into performance problems (and memory leaks) when he took out the GC!