[Gc] Slightly off topic: Are there any benchmarks comparing the speed of gc v non gc?

Bruce Hoult bruce at hoult.org
Thu Jan 17 03:10:16 PST 2008


On Jan 17, 2008 11:50 PM, Alexander Petrossian (PAF)
<Alexander.Petrossian at teligent.ru> wrote:
> Sean Cross @ Thursday, January 17, 2008 1:41:39 PM (Moscow time):
> SC> Are there any publicly available benchmarks that would demonstrate the truth
> SC> or otherwise of this?
>
> Sean,
> this subject was brought up several times in the past,
> quick answer is "were, but no good -- first people should agree on testing method".
> longer answers are in mailing archives.

If it's easy to determine when and where to call free then gc is
likely to be slower.  Notice though that in the past many OS or
compiler runtime libraries were very bad and simply using Boehm GC as
a mamory manager using malloc/free exactly where they always were
speeded up programs a lot.  This was true as recently as five years
ago on many platforms, and may well still be true on some now.  So in
those cases, using Boehm as a GC was/is better as well.

Comparing Boehm malloc/free to Boehm malloc + GCs, if you can simply
determine a place in your program where something can be freed then I
find it is a win to do so. e.g. a temporary variable used only in one
function.  But alloca() is better still, if you can afford the stack
space and your compiler & ABI & runtime library allow the intended
implementation (i.e. it's not faked with malloc()/free() anyway).

BUT, if you need to maintain a reference count in order to know when
to free the memory then it's faster (but uses more memory) to ditch
the reference count and just rely on the GC.

If you'd need to catch exceptions, free memory, and rethrow the
exception (or use a "finally" clause in appropriate languages) in
order to get an object freed then it's *far* faster to forget it all
and just use GC.


More information about the Gc mailing list