>>>>> "NS" == Neil Schemenauer <nas@python.ca> writes: NS> Jeremy Hylton wrote: >> I've noted before that it doesn't make much sense to invoke GC >> unless there is at least one deallocation; you can't reclaim >> anything if there are no DECREFs. NS> It's easy to add a decref counter. It doesn't seem to help much NS> though based on my limited testing. The standard test suite NS> does not trigger it. I can't get our web application to either. NS> Is it worth checking in? Maybe someone can come up with a NS> better trick. I'm not sure what your trick is, since you've only described it as a "decref counter." It may not be what I was thinking of. Regardless of whether it is, my idea may not be any good either. I was imagining a scheme like this: Count increfs and decrefs. Set two thresholds. A collection occurs when both thresholds are exceeded. Perhaps 100 decrefs and 1000 increfs. NS> Note that we must take into account generations as well. If NS> threshold0 is low then there are lots of quick collections. NS> Setting it larger does not help too much as new objects will NS> eventually be examined (unless they are destroyed before the NS> next collection). How does this come into play in the benchmark in question? It seems like we should have gotten a lot of quick collections, but it was still quite slow. Jeremy
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