brisbane: initial cut at a mergeline cache

[Ian Clatworthy]

Ian Clatworthy wrote:

So the key thing I forgot to mention is that this makes *all*
operations on a non-mainline revision faster, not just log.
For example:

* bzr log -rx.y.z  drops from 6.03s to 0.75s
* bzr st -rx.y.z   drops from 5.87s to 1.68s
* bzr diff -rx.y.z drops from 6.49s to 2.09s

And that's just bzr.dev - really large projects like Emacs & OOo
will see *much* larger reductions.

> 2. The size of the mergeline-store file for bzr is 211K, about
>    the same as dirstate.

Compressing this (zlib) drops the size down to 76K. The reduction
is important because, unlike dirstate, we might need to write this
over a network. Time to write the file from Brisbane (the location)
to London is ~ 5secs for me, out of a total of 2m4s for

  bzr log -rx.y.z sftp://ianc@ubuntu.com/...

With the mergeline-store saved, the time improves to 1m15s. Nice.

> 3. Updating a cache in the middle of a 'read' operation causes
>    grief I don't know how to fix. How does one go about promoting
>    a read-lock to a write-lock in bzrlib?

I've worked around this in the latest patch by updated the cache
on disk after the read transaction completes. I'm less than happy
with what that implies: an extra flush() method on branch() that
commands in builtins.py needs to remember to call after b.unlock().
If there's a way of making unlock() do this magic implicitly,
I'd be much happier. Certainly *I* couldn't make it work thanks to
our decorators that put each of my attempts into endless
recursive loops. :-(

Thoughts?

Ian C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mergeline-cache-2.patch
Type: text/x-diff
Size: 22323 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090330/1ec5b02b/attachment-0001.bin