[MERGE] hack logging to not always do whole history operations
Michael Hudson
michael.hudson at canonical.com
Fri Mar 14 02:42:18 GMT 2008
In the continued spirit of
http://blog.orebokech.com/2008/03/emacs-in-bzr-initial-impressions.html
I got to thinking that log --line and log --short do not need to do
whole-history operations. The result was the attached patch, which is
rather hackish.
Here's the good side (in Jason's emacs cvsps-import):
mwh at grond:trunk$ time bzr log --short -l 10 | wc -l
41
real 0m8.883s
user 0m8.417s
sys 0m0.424s
mwh at grond:trunk$ time ~/src/bzr/cheaper-simple-logging/bzr log --short
-l 10 | wc -l
41
real 0m0.248s
user 0m0.216s
sys 0m0.036s
(Which is ~45x faster, much more if you take startup time into account).
But, it makes logging the whole history slower (~60s vs ~45s) -- I guess
because we're now calling get_revision 80000+ times, not ~1000. For bzr
log --short | less usage though, the first few revisions appear much
more quickly.
For full log, I guess you could do hacks like, use this approach until
you see a revision with two parents. But that would get a bit
hair-raising I guess. Or you can do things by graph walking rather than
merge_sorting, but this sounds complicated too. But it's probably
going to be necessary when we bump into even bigger histories than emacs'.
Cheers,
mwh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bzr-mail-KArsE6.patch
Type: text/x-diff
Size: 11654 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080314/7070b7ca/attachment-0001.bin
More information about the bazaar
mailing list