should avoid __del__ in non-debug mode

[Martin Pool]

Having a __del__ method on an object can impair Python gc performance, even if the del method does nothing interesting.

bzr's coding conventions generally ban del methods that have external effects, such as closing a file, because there is no guarantee they will be called at the right time. However we do currently have some that just warn the developer the object was not closed.

We could instead only install those methods when eg -Dleaked is set, so that in the normal case they won't interfere with gc.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/2/2011 1:35 AM, Martin Pool wrote:
> Public bug reported:
>
> Having a __del__ method on an object can impair Python gc performance,
> even if the del method does nothing interesting.
>
> bzr's coding conventions generally ban del methods that have external
> effects, such as closing a file, because there is no guarantee they will
> be called at the right time. However we do currently have some that
> just warn the developer the object was not closed.
>
> We could instead only install those methods when eg -Dleaked is set, so
> that in the normal case they won't interfere with gc.
>
> ** Affects: bzr
> Importance: Medium
> Status: Confirmed
>
>
> ** Tags: debug memory tech-debt
>
> ** Tags added: debug memory tech-debt
>

If you are saying "non-debug" mode you could also do:

 if __debug__:
    def __del__(self):
      ...

However, those objects were intentionally crafted to hang off the end of
a cycle, rather than participate in it. I thought we were pretty careful
with it. (Common state was factor out, and is only accessed through the
object with __del__, etc.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3s5xUACgkQJdeBCYSNAAMIBwCcCn+0eU6VcsmoM/xCvRmxGYV3
OIIAoM9CMG6Y2Qbygu1AgJ6Seywmw7FQ
=rT23
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

On 7 June 2011 00:41, John Arbash Meinel <email address hidden> wrote:
> If you are saying "non-debug" mode you could also do:
>
>  if __debug__:
>    def __del__(self):
>      ...

Pretty much that, though I would probably check debug_flags rather than -O.

> However, those objects were intentionally crafted to hang off the end of
> a cycle, rather than participate in it. I thought we were pretty careful
> with it. (Common state was factor out, and is only accessed through the
> object with __del__, etc.)

I know, but it was mentioned in the recent thread & irc discussion
about gc that even this may slow down gc, so we could look at getting
rid of it. Also, those messages probably have negative value to
non-developer users. (I suppose it's just possible that they would be
enlightening if the user is already experiencing a bug, but if we
suspect something related to objects not being released, we could
always ask them to turn it on.)

Martin

[Martin Pool (mbp)]

bug 803187 is the follow-on to do an api change that will allow this to also be cleaned up for ssh.