Cast not your Perl before swine?

Levi Pearson levi at
Tue Dec 18 10:01:20 MST 2007

Dave Smith <dave at> writes:
> I don't understand how the C program's heap got fragmented when all
> the mallocs were of the same size, and freed in order. This means that
> they *should* all end up getting allocated in the exact same address
> (or at least close), which would require almost no searching. Seems to
> me like it shouldn't be *that* much slower than the Java allocator.

In that example, the C's heap didn't get fragmented.  The allocator is
a general-purpose one, though, so it has to do all sorts of 'smart'
things to deal with real-world stuff in order to attempt to minimize
heap fragmentation and deal with it when it does happen.  So, even
though they could all get the same address, malloc doesn't know that,
so it has to go through its motions anyway.

So, you have Java that gets to simply increment a pointer for ever new
object creation, and doesn't have to try to free anything until the
heap is full, so it probably only has to run GC a couple of times, if
that.  Then you compare that to C, which has to call malloc, which has
to do some calculations, update some records, etc.; and then call
free, which has to update some records, etc.; and you can see why C is
so much slower in this case.

The fact that this is completely unlike any real program makes it a
nice party trick, but not a great benchmark for real-world GC


More information about the PLUG mailing list