This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vdupras
Recipients ajaksu2, dcjim, pitrou, vdupras
Date 2009-02-14.14:11:26
SpamBayes Score 3.3729686e-12
Marked as misclassified No
Message-id <1234620688.95.0.248859697892.issue839159@psf.upfronthosting.co.za>
In-reply-to
Content
About duplicated code and performance:

When I look at the duplicated code, I don't see anything that remotely 
looks like a performance tweak. Just to make sure, I made a bench:

#!/usr/bin/env python
import sys
sys.path.insert(0, 'Lib')
import timeit
import weakref

class Foo(object): pass
def setup():
    L = [Foo() for i in range(1000)]
    global d
    d = weakref.WeakValueDictionary(enumerate(L))
    del L[:500] # have some dead weakrefs

def do():
    d.values()

print timeit.timeit(do, setup, number=100000)

Results without the patch:
 ./python.exe weakref_bench.py
0.804216861725

Results with the patch:
$ ./python.exe weakref_bench.py
0.813000202179

I think the small difference in performance is more attributable to the 
extra processing the weakref dict does than the deduplication of the 
code itself.

About the test_weak_*_dict_flushed_dead_items_when_iters_go_out:

If a weakref dict keeps its weak reference alive, it's not an 
implementation detail, it's a bug. The whole point of using such dicts 
is to not keep keys or values alive when they go out.
History
Date User Action Args
2009-02-14 14:11:29vduprassetrecipients: + vdupras, dcjim, pitrou, ajaksu2
2009-02-14 14:11:28vduprassetmessageid: <1234620688.95.0.248859697892.issue839159@psf.upfronthosting.co.za>
2009-02-14 14:11:27vdupraslinkissue839159 messages
2009-02-14 14:11:26vduprascreate