[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4