[RFC/MERGE] Updates to decorators

John Arbash Meinel john at arbash-meinel.com
Fri Jan 12 15:30:41 GMT 2007

Hash: SHA1

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:
>   http://oubiwann.blogspot.com/2006/08/python-and-kcachegrind.html
> 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
can do:

bzr --lsprof-file filename command

And then:

>>> 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()


Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list