brisbane: initial cut at a mergeline cache

[Robert Collins]

On Mon, 2009-03-30 at 14:53 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> 
> > Don't update on read operations, its not safe, and unlike dirstate there
> > is no need to do so as only write-locked operations can change the state
> > it would cache.
> 
> I don't think that's an option. The whole basis for the design is *not*
> to impact write operations in any way, just save some key data calculated
> during the first read operation, making subsequent ones are faster.

Then I think the design is definitely wrong and needs reevaluation. This
data is known during write, and reads outnumber writes immensely;
penalising the most common operation is a serious issue. Or does the
cache write to somewhere other than the branch? 

>  Without
> this approach, it will *never* be scalable for the very reasons you needed
> to abandon the old cache you mentioned.



> And we need *some* answer, if not the mergeline cache. It simply isn't
> realistic to tell projects like OOo that
> 
>   bzr log/st/diff -rN
> 
> takes a few seconds as long as N isn't off the mainline ('cause then
> it will take a few minutes).

I appreciate we need to fix it. We've had a great deal of success
analysing the root cause of performance isues and coming up with a
design. Look at brisbane-core's disk format for instance - that took a
bunch of effort to come up with a conceptually simple, elegant, and well
performing solution.

So lets look at what is going on and why it needs a cache.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090330/0536ad15/attachment.pgp