Python vs Ruby
nas at arctrix.com
Thu Feb 1 11:59:55 CET 2001
On Wed, Jan 31, 2001 at 06:53:24PM +0000, hansboehm at my-deja.com wrote:
> [Neil Schemenauer]
> > RC also works quite well with data caches and VM managers. Using
> > the Boehm-Demers GC with Python and disabling reference counting
> > slows the interpreter down by a significant amount.
> Are you sure the collector is working correctly, and not retaining
> garbage for some reason? I looked at the source tree quickly, and it
> appeared to me that the interpreter maintained a doubly linked list of
> all Python objects? That would effectively keep the collector from
> reclaiming anything. Is that list essential?
That linked list is only used if the cyclic garbage collector is
enabled. It has been quite a while since I played with your GC,
before the linked list stuff was added to Python.
> When I last looked at this 4 or 5 years ago, there were some other
> issues that prevented a direct plug-in of a tracing collector. I think
> some subsystems did their own free-list management. This tends to be a
> pessimization with a tracing GC, especially if the objects on the free
> list still point to other long-dead objects, etc. I couldn't find such
> issues now, but I didn't look very hard.
Those freelists are still there. I don't doubt that I could have
made your GC perform better. My tests were very un-scientific
and should not be given much weight. Mark and sweep GC will
probably be considered for Python 3000 (at least I'm going to
look at it again).
> Reference counting tends to look considerably worse if you fully support
> concurrency, so that you have to update reference counts with atomic
Right, that is one of the big problems with "free threading" the
current interpreter. Currently the interpreter is protected by
one big lock. Again, this is probably something that will be
considered in the Python 3000 design.
Thanks for your comments.
More information about the Python-list