[MERGE] log performance

John Arbash Meinel john at arbash-meinel.com
Fri Jun 23 21:24:08 BST 2006


Aaron Bentley wrote:

>>> One problem with demand_compile is that it switches from having one file
>>> which takes 30ms to load, to having 5 6ms compile times spread around
>>> based on the first use. So while it looks like you fixed the big
>>> penalty, you really just spread it around.
> 
> 1. If it lets us start spitting info back at the user sooner, even if it
> takes just as long to complete, it's still a win.
> 2. Surely there are some regexes that aren't used...

There are. But at this point in my demandload branch, I've eliminated
most of them for other purposes.
One of the nice things about 'demand_compile' is that you have to do a
lot less work to get similar speedups.
For example, if you are okay with modifying re.compile(), you don't have
to hack around the slowness of importing tokenize.

Just putting a wrapper around 're.compile' in a stock bzr.dev tree
changes my 'bzr root' time from 466ms down to 320ms.
So with all the stuff we are importing, we are spending 140ms just
compiling regexes.
If we wanted to be really fast, we would serialize compiled regexes, so
that the first bzr load would create them, and then the demand compiler
could just look them up in the mapping. From my understanding this is
what some of the python C inliners do (weave, as I recall keeps a .so
cache in ~/.something).


> 
>>> (demandloaded 'bzr --no-plugins --no-aliases rocks' is down to 70ms).
> 
> Okay, so we still need to fix ConfigObj.  Sigh.
> 
> Aaron

Well, the regex that checks for lists costs about 6ms. Importing plain
ConfigObj takes 35ms originally (down from 135ms after removing
validate.py).

One small issue with my current 'demand_compile' is it returns a proxy
object, which never replaces itself.
I think if we are willing to inspect sys._getframe(), we could actually
create an object which would replace itself in the calling scope. But
that is *really* evil.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060623/fe1c33f5/attachment.pgp 


More information about the bazaar mailing list