[Python-Dev] impact of cycle gc...

[Skip Montanaro]

    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