[Gc] Faster to not call GC_free?
Hans.Boehm at hp.com
Sat Jun 2 17:41:47 PDT 2007
I haven't measured this recently. My guess, based on some older
measurements, is that for small object with threads, stubbing out the
GC_free may be s substantial win. GC_free always acquires a lock,
which often dominates everything else. Even in the single-threaded case,
the collector is generally significantly faster at reclaiming small
objects than GC_free.
With very large objects, the opposite is generally true, often by
a large margin. Calling GC_free on these effectively pushes back the
next garbage collection significantly, and it's a relatively cheap
So, as usual, the short answer is "it depends".
On Sat, 2 Jun 2007, jim marshall wrote:
> I'm using GC 6.8 in my application, we have designed the application to
> have its memory management be interchangeable (e.g. use GC, dmalloc or
> normal CRT malloc). As such we have designed our application to have our
> own internal allocation routines (mainly macros or inline functions).
> After doing some reading the indication I get is that I maybe better off
> stubbing out our gc_free calls with no-ops or something like
> #define intFree(vptr) vptr=NULL
> Any thoughts on if this is worth while doing?
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc