Creating a roadmap for improving bzr's performance.

[Matthew D. Fuller]

On Thu, May 10, 2007 at 05:29:36PM +1000 I heard the voice of
Martin Pool, and lo! it spake thus:

Y'know, I always feel kinda funny responding to this sort of thing.  I
mean, I'm making seemingly obvious observations about things I vaguely
pay attention to, to people who specialize in them.  It seems a little
pointless and arrogant.  But, I'm a pointless and arrogant person, so
I guess I can get away with it.


> And here are some things that are well established in Bazaar, but I
> would say very much up for consideration:

[...]

> * caching line-by-line annotations at commit time

This is one thing that bugs me.  It ties those annotations to what we
think of them at commit time; if we come up with a "better" diff
algorithm later, those annotations can't make use of it.  It also ties
the diff we display to the diff we store to the diff we merge.  For
storing, we probably want a minimum diff, but for display we want a
"friendly" diff.

It imposes a restraint that the storage must be line-based, since the
annotations are by line.  I don't know if we'd want to try pushing
annotations down to a tighter granularity than the line, and I don't
think displaying sub-line diffs is the friendliest, but _storing_
binary diffs likely often makes sense from a space perspective, and
may be a gain in time.


> * recording per-file graphs - this is largely redundant with the
> whole tree graph, and I think only used for per-file log?

I thought it was (conceptually at least) also useful for cherrypicking
by file.



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.