Jeremy> I don't have time today to look at your post in detail, but one
Jeremy> thing you said rtiggered a pretty immediate response: We should
Jeremy> worry more about the GC performance on examples like the one you
Jeremy> posted, and less about pystone.
I wasn't really worried about pystone, just looking for something quick that
didn't generate cycles... ;-)
Your suggestion is an excellent one. To try and account for the typical
case, I modified the test slightly. I added a new class, ethyl:
def foo():
pass
class ethyl:
def __init__(self):
self.indirectFunc = foo
def theFunc(self):
return "blah"
which performs essentially the same work at instantiation time as fred, but
doesn't create a cycle. The time (in seconds) to create and delete 100,000
freds and ethyls with and without cycle-gc enabled looks like (last of six
consecutive runs):
./python ./python-cycle-gc
fred (cycle) 1.4 2.51
ethyl (no cycle) 1.39 1.55
The memory consumption is as you would expect - leaky when creating fred's
without using cycle-gc, stable otherwise.
So, the penalty for creating and deleting objects that don't contain cycles
would appear to be reasonable (about 10-15%). As more experience is gained
with it, I imagine it can be reduced further.
Skip
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