Interesting speed benchmark

[John Roth]

"Peter Herth" <herth at netcologne.de> wrote in message
news:87elswq9e6.fsf at netcologne.de...
> 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

Garbage collection is an interesting topic, however, it seems to me that
Python has a major hurdle moving to a modern (i.e. incremental)
garbage collection process, namely extension types.

Any form of garbage collection has to be able to locate all of the objects.
With Python's built-in types, this isn't much of a problem, but for a
foreign
type, any references to other objects have to be made visible by the
implementation
of the type, so retrofitting a real garbage collector would break a lot of
extensions.

The other hurdle is that garbage collectors trade off overhead in collecting
garbage by providing a memory model that makes it very fast to allocate new
memory. Compacting memory also requires being able to locate all pointers
to objects, and with low level extensions, that could present very difficult
to debug problems.

Python 3000 anyone?

John Roth