[Python-Dev] Python 1.6 timing (fwd)
Tim Peters
tim_one@email.msn.com
Sat, 22 Jan 2000 18:29:45 -0500
[hristian Tismer]
> ...
> Even better: Refcounting can lead to many new optimizations
> if we pay the cost to make INCREF/DECREF into methods. It
> has its cost (about 10 percent less pystones), but massive
> long-term benefits.
The GC patch Guido forced <wink> me to look at is based on the observation
that it's impossible to create cyclic trash unless a decref leaves a nonzero
refcount. So the patch adds a function call to the DECREF macro (if the new
refcount is > 0, the object must be added to the set of "suspicious"
objects; else the object must be removed from that set).
So it roughly adds the cost of a method call to each decref anyway. You
would think it adds less <wink>, but "the set" now is represented as a splay
tree, so *gobs* of hairy code get executed in either case (splay trees do
mutating rotations even on a lookup).
> ...
> Conclusion: I vote for a kind of GC that does just what
> refcounts cannot do, but please keep with the refcounts.
I like 'em too!
BTW, Toby posted (at least an earlier version of) the patch to c.l.py, if
anyone else wants to dig into it (I may have mentioned before that I'm short
on time <wink>).