© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Just to post my numbers...
In the 5.1 branch I get:
bzr.dev
% time bzr annotate --show-ids sql/sql_parse.cc >/dev/null
34.89s user 0.32s system 97% cpu 36.283 total
% time bzr annotate --show-ids sql/sql_insert.cc >/dev/null
4.70s user 0.10s system 93% cpu 5.136 total
With the branch associated with this bug, I get:
% time ~/dev/bzr/
11.56s user 0.13s system 99% cpu 11.739 total
% time ~/dev/bzr/
2.12s user 0.07s system 85% cpu 2.577 total
Now, 'gannotate' is doing a little bit more work, but mostly I wanted to point out the relative improvements. Specifically, 35s => 11.5s, and 4.7s => 2.1s.
So somewhere from 2-3x faster.
I'm also working on a proposal to start building annotation caches, which could easily get these numbers to drop below 1s. (The current algorithm has to evaluate all of the revisions of a file, which obviously gets slower the more commits you make. With a cache at appropriate times, you can limit the amount of history you need to inspect.)
Including a cache is going to take a bit more work. There is always a "quick-and-dirty" solution which would only work locally. But ideally you'd like to be able to transmit the cache so that everyone doesn't have to build it. Which starts to bring up efficiency issues during transmission.
I'll also be posting a couple of patches to bzr-gtk which will make jumping around in history faster. Specifically, it is much easier to grab an in-memory cache of the intermediate revisions.
Oh, I should also mention that the associated branch decreases memory consumption dramatically. On mysqld.cc it dropped it from 250MB => 50MB. I don't know how much RAM you have in your machine, but getting close to swap / running out of room for disk buffers would certainly impact performance dramatically.