Skip, I don't have time today to look at your post in detail, but one thing you said rtiggered a pretty immediate response: We should worry more about the GC performance on examples like the one you posted, and less about pystone. pystone is a good benchmark for testing the overhead in cases when the garbage collector isn't invoked. There's so little memory allocation that nothing interesting happens. The GC patch ought to have no effect in this case. I suppose 4% is okay. The worry is about programs that allocate a lot of objects, even if they never create circular references. The compiler test is one example, because the parser tree consumes an enormous number of tuples and objects. I suspect big slowdowns like the one you posted just mean we don't know how to adjust the tuneable parameters. 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