Loggerhead directions

[Ian Clatworthy]

On 15/04/10 06:10, John Arbash Meinel wrote:

> The better, the cache can be shared between all branches. So switching
> from emacs/trunk to emacs/feature1 to emacs/feature2 will be avoid the
> 'fresh-start w/ on disk cache' performance, and even better always
> avoids the 'fresh start no-disk cache' performance. So once you've done
> the 30s import. Your worst-case time becomes closer to 700ms, (440+188)
> rather than 13000ms when a new feature branch is browsed.

That's certainly a major improvement over the per-branch architecture of 
my historycache plugin. I'm curious though about how stacked branches 
play in with this? Can you chain the caches so that the cache for a 
stacked branch gets deleted if and when a stacked branch is deleted?

> So now I'm trying to figure out if I should go back to at least an
> in-memory cache, and populate it from the data I query via bzrlib apis,
> or whether I should just mandate that bzr-history-db is available.
> If I do the latter, then I may as well change the Loggerhead code to
> query the database directly, and only use stuff like
> Branch.last_revision()...
>
> Some minor guidance would be appreciated.

In terms of performance tuning, I think you ought to assume that 
history-db or equivalent is deployed. In terms of dependencies though, 
you should assume it's *not* there. In other words, please go via 
bzrlib, even if you need to introduce new Branch and Repository APIs, to 
access data.

Why do I say that? I suspect 90% of projects on any hosting site are 
small to medium in size. They *may* benefit from history-db but 
Loggerhead ought to perform fine for those branches without it. By 
sticking with bzrlib APIs, we can selectively enable history-db only on 
large projects, at least until a descendant of it makes it into the core.

On a semi-related topic, I'm hoping to do a review of Loggerhead's UI 
soon and look at what we can take out to get closer to O(1) performance. 
For example, I don't think that we need to render the revno column in 
the Files view. (I'm planning to introduce one or more configuration 
settings that will control whether that data is displayed or not.)

Ian C.