> The difficulty is with apps that grow a lot of long-lived containers > that aren't trash and don't even contain cycles. There's no bound > on how often they'll get crawled over looking for trash that ain't > there, and the more of those you grow the longer it takes to look at > them. When a gen2 collection doesn't find any trash, it should > probably become less eager to try looking at the same stuff yet > again. Adding more generations could have a similar good effect. > > Half of a shadow of an idea: at least in my code, it's common to > have gazillions of tuples, and they almost always contain just > strings and numbers. Since they're immutable, they'll never contain > anything else. So they could get unlinked from cyclic gc entirely > without ill effect (it's not possible that they could ever be in a > cycle). Perhaps a gen2 collection could learn something about this > and automagically untrack them. Different (complementary) idea: how about having more generations, each being traversed less frequently than the previous one? Maybe a (potentially) infinite number of generations? (Or at least a fixed limit that never gets reached in practice.) Wouldn't this have the same effect as increasing the threshold exponentially? --Guido van Rossum (home page: http://www.python.org/~guido/)
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