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