[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