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