[Jeremy] > It acts about the same on Linux. Also in 2.2.1? Guido presented some evidence there that's getting increasingly hard to believe (in part because holger krekel couldn't verify it, and in larger part because you found the true cause below <wink>). > I don't see why it's a mystery. justtups() only uses one tuple at a > time; it gets re-used from the free list every time. storetups() has > to (py)malloc a new tuple every stinkin' time. It's a mystery because it's not credible that falling back to pymalloc is *that* much slower than using the tuple free list. > Note that there's a net excess of allocations in the storetup() case, > so we invoke the garbage collector every n/700 times through the > loop. Bingo! This also explains Guido's quadratic-time behavior. If I do gc.disable() at the start of this test, storetups() drops to under 1 second. So, also, the pymalloc burden is indeed comparatively trivial. > 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. Let's see whether Neil can resist <wink>.
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