[RFC/MERGE] Updates to decorators
John Arbash Meinel
john at arbash-meinel.com
Fri Jan 12 15:30:41 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Olivier Grisel wrote:
> John Arbash Meinel a écrit :
>> I have 2 updates to our current decorators, one follows on the other
>> one, but is a little more controversial.
>> Basically, I've been doing lsprof testing, and I've been getting
>> frustrated with the 'read_locked()' functions. Because in a big test,
>> you can have 10 or more @needs_read_lock functions. So when you are
>> tracking up from the bottom, or down from the top, you frequently hit a
>> barrier which makes it difficult to tell who is calling what. (10
>> functions call "read_locked()" and read_locked calls 10 other functions,
>> so which is being called without going to the source?)
> Kcachegrind provides a nice UI to browse the calltree of a profiled python run.
> There exists a python script to convert lsprof output to kcachegrind input:
> Hope this helps,
I have heard of that, and we even have a Kcachegrind output for our
lsprof objects. David Alouche did some nice work there. So I believe you
bzr --lsprof-file filename command
>>> import cPickle
>>> prof = cPickle.load('filename')
>>> prof.calltree(open('file.kcachegrind', 'wb'))
Thanks for reminding me.
However there still is the problem that in the middle of everything you
have a bunch of functions calling the same function, which then fans out
to multiple other functions.
Specifically anything that has a '@needs_read_lock' decorator goes
through 'needs_read_lock' which creates a wrapper function 'read_locked'.
Now it might be possible if lsprof tracks the inbound to a function to
the outbound. Specifically if it can tell the difference from:
bar() => intermediate() => real_bar()
baz() => intermediate() => real_baz()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar