[MERGE] log performance

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> But in general, using a generator over 1000 items is *much* faster than
> calling a standard function 1000 times. We might also keep that in mind
> with our current code, trying to build things into lists and calling a
> generator over them.

There are many, many places where we generate lists and could as easily
use generators.  So I guess we should keep our eyes peeled for instances
where list.append() is taking significant time.

>>Yeah, the only chance of changing --long would be by avoiding 6500
>>hasattr calls.
> 
> 
> Probably an improvement, but not necessarily a lot.

That overhead was barely visible in lsprof output, IIRC.

> Heck, with my 'bzr service' plugin, we could get the startup time down
> to low ms. But that probably isn't a general solution.

It would be fairly evil to have the first instance of bzr spawn a daemon
and communicate with it. :-)

> With all my hackery I can get 'bzr rocks' time down to around 100ms. And
> 'bzr root' time down to 215ms.

I think Branch.open_containing('.') should be cheaper than 115 ms.

> 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...

> (demandloaded 'bzr --no-plugins --no-aliases rocks' is down to 70ms).

Okay, so we still need to fix ConfigObj.  Sigh.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEnEOD0F+nu1YWqI0RAierAJ4ul5beIKuVCBY/if8kRRoUX2o0HACeKsVb
DSStIo89lmijY5BfyOzOzDA=
=rh5f
-----END PGP SIGNATURE-----