[Python-Dev] Lazily GC tracking tuples
Wed, 8 May 2002 00:53:38 -0400
[Neil Schemenauer, on Daniel Dunbar's interesting tuple-untrack scheme]
> I'm not sure I like this approach. Slowing down PyTuple_SET_ITEM to
> optimize a micro-benchmark seems dubious. However, dropping the number
> of tracked objects by 50% _does_ seem worthwhile. Couldn't we get the
> same effect by checking and untracking the appropriate tuples after
> finishing a gen1 collection? Each tuple would be checked once and short
> lived tuples will probably not be checked at all.
I agree with Neil here. Do you really mean after a gen1 collection? Or
after a gen0 collection? Or before a gen2 collection <wink>? The
micro-optimizer in me would like to combine testing for "safe to untrack"
objects with the whole-list crawl being done anyway in update_refs() at the
start of a collection. Offhand I guess I'd do that at the start of a gen0
collection. If that untracks a tuple that was going to die soon anyway,
it's not really a waste of time, because untracking at the very start saves
the rest of the collection from crawling over it twice (subtract_refs won't
see it if it gets untracked, and ditto move_roots). So that seems a net
win. OTOH, it that decides a tuple isn't safe to untrack, and the tuple was
going to die soon anyway, it's an "extra" peek at the tuple guts. That's a
net loss. But I expect an overwhelming majority of tuples are safe to
untrack, so playing a frequent net win against an infrequent net loss seems
a net win.