Interesting speed benchmark

[Peter Herth]

msoulier at storm.ca (Michael P. Soulier) writes:

> On Thu, 7 Jun 2001 10:40:04 +1000, Delaney, Timothy <tdelaney at avaya.com>
> wrote:
>     This makes sense, but if Python is doing less allocation, that should also
> be a time saver, no? Or did the performance increase in lazy GC just so far
> outweight the benefits of less malloc() calls that it didn't matter here?
> 
>     Mike

Well that depends very much on the kind of program at hand:
If, as in the example, the allocated pieces of memory have a very
short living and get only referenced once, a reference-counting
implementation of a GC is perhaps the fastest solution. But 
reference-counting has 2 big drawbacks: any referencing of
an object has an additional cost of the reference count bookkeeping,
and it cannot deal with cyclic references. Furthermore, memory
might fragment, and this makes malloc() a rather expensive operation.

Other garbage collection techniques do not have the extra cost at
referencing objects, but cleaning them up usually involves inspecting
part or even the whole heap to determine what can be collected.
This is of course a very time-intensive operation, but depending on
the requirements of the program can still be much faster than
reference counting.

One common approach taken in modern garbage collectors is generational
collection: objects on the heap are put into "generation" depending on
their age, garbage collection runs mostly look only at the youngest
objects, so all the short-living temporary objects can be cleared
with very low overhead. If the collectors do some compacting of the
heap in the process, the speed of allocation can be *greatly* increased,
to the point where heap allocation is as fast as stack allocation.
(In my experience, most of the impressive speed-up of Hotspot comes
through the generational GC)

Peter


-- 
Dawn of the Ages       http://dawn.netcologne.de