"pause" garbage collection in parallel code

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 15 10:02:55 PST 2014


On Mon, Dec 15, 2014 at 11:26:26AM +0000, bearophile via Digitalmars-d wrote:
> Stephan Schiffels:
> 
> >2.) Is there a way to "pause" the GC collection for the parallel part
> >of my program, deliberately accepting higher memory usage?
> 
> There are GC.disable and GC.enable.
[...]

Recently in one of my projects I achieved dramatic performance boosts by
calling core.memory.GC.disable() at the beginning of the program, and
manually calling GC.collect() at a reduced rate (to keep total memory
usage down). If you're having performance trouble with the GC, this
could be a good way to deal with the situation. I almost halved my
running times (== doubled performance) just by limiting the rate of GC
collection cycles.

I also achieved significant boosts by using a profiler to track down
hotspots that turned out to be some obscure piece of code that I
overlooked, that was overly-eager in allocating memory, thereby
incurring a lot of needless GC pressure. Just a couple of simple fixes
in this area improved my performance by about 10-20%.  In one case I
manually called GC.free() to collect dead memory that I know for sure
there are no other references to -- this also reduces GC pressure and
allows you to reduce the frequency of GC.collect() calls. (There's a
caveat, though; if you call GC.free() on memory that's still being
referenced, you might introduce segfaults and memory corruption into
your program. Generally, I'd advise to do this only in simple cases
where it's easy to prove that something is unreferenced. Anything more
than that, and you end up reimplementing the GC, and you might as well
just call GC.collect() instead. :-P)
 

T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.


More information about the Digitalmars-d mailing list