John Arbash Meinel john at
Mon May 22 20:59:22 BST 2006

I've been doing more profiling, and I've found a few of the big import
slowdowns. Generally, these are the things that cost time when we are
doing 'time bzr rocks', which is the most 'no-op' that we can get.

On my machine, with a stock bzr, it takes 343ms to run 'bzr rocks'.

These are the worst offenders. Note that the times listed here are to
import that file (which includes the time to import other files, etc)

20ms doctest (for iterablefile)

31ms elementtree
34ms cElementTree

32ms tokenize for inspect
35ms inspect for copy

35ms validate for bzrlib.util.configobj.configobj
57ms bzrlib.util.configobj.configobj
70ms bzrlib.config

One of the big things, is that it seems 're.compile()' is pretty slow.

That is why 'validate' is so expensive for configobj, and it looks like
why tokenize would be expensive.
It also seems to be why 'import elementtree' is expensive, since it
does: re.compile(eval(r'u"[&<>\"\u0080-\uffff]+"'))
it uses the convoluted eval() because it wants to support python 1.5
which didn't have unicode. My testing says that compile cost 25ms of the
32ms cost of elementtree.

Actually, the import tree for a plain 'bzr rocks' has ~700 imports.

In my demandload tree, I have delay loading for cElementTree, and for
'bzrlib.config' which brings the time down to only 76ms, which is very
fast. However, it means that we can't fallback to ElementTree. Also, you
have to supply --no-aliases and --no-plugins, because Aliases require
reading ~/.bazaar/bazaar.conf for aliases, which forces loading
bzrlib.util.configobj.configobj, which is naturally slow.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : 

More information about the bazaar mailing list