weakrefs and avoiding bad gc cycles

[Barry Warsaw]

I don't have a whole lot to add to this thread, except for one experience I
had in a application I worked on in a previous life.  This was a potentially
very long running app (but not a daemon) that created and freed tons of
objects.  None were huge but lots of cycles were created and __del__ was not a
problem.

The issue we hit was the time spent by Python in essentially gc.collect().  It
turned out that a huge number of our objects were ending up in generation-2
before the cycles they participated in were collectable.  Late in the run,
Python would spend a huge amount of time just iterating over generation-2
objects.  This is actually why I added the optional `generation` argument in
gc.collect() back in the Python 2.5 time frame.

This may have no relevance to bzr, but it is useful to remember that while
most programs can safely ignore the costs of cyclic gc, it can come back to
bite you in some cases.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110601/cf563e58/attachment.pgp>