A couple garbage collector questions

Carlos Alberto Reis Ribeiro cribeiro at mail.inet.com.br
Tue Apr 3 07:31:01 EDT 2001


At 10:02 03/04/01 +0200, Daniel Dittmar wrote:
> > Something nobody has mentioned yet is that RC is cache-friendly,
> > whereas pure M&S is quite cache-hostile. This is important
>
>But RC is quite thread hostile (as you have to lock on increment/decrement).
>Not a problem in current Python because of the global lock, but possibly
>limiting in the future.

I believe that mark and sweep may behave even worse with threads. You'll 
have to use locks anyway, but it's possible that you need to keep the lock 
much longer.

As for the *total* amount of work needed, I believe that it is 
approximately constant for any decent garbage collector. What changes is 
(mostly) the distribution in time. Why? The number of destructors calls is 
going to be the same for any GC (except for any memory leaks :-). If you 
have objects with slow destructors, they're going to dominate the time for 
GC anyway. So the total amount of time spent in the GC is going to be about 
the same, regardless of the algorithm (as I have said, for any *decent* GC).

The way the GC distributes its work along time changes the *perception* of 
the performance. Some GC cause long pauses, and that is perceived as a bad 
thing, because it affects the responsae time, sometimes in a unpredictable 
way. I think that this is an advantage of the ref-count GC used by Python. 
It's not *absolutely* predictable, but it does a good job in GC'ing objects 
as soon as they're dereferenced, making for a smoother process without the 
bumps normally associated with "other" popular GCs in the market.


Carlos Ribeiro






More information about the Python-list mailing list