[Python-Dev] Lazily GC tracking tuples

[Tim Peters]

[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.