history-db, now speeding up 'bzr log'

[Ian Clatworthy]

On 13/04/10 08:05, John Arbash Meinel wrote:

> Results:
>
> 1) We could probably get rid of a bunch of the special casing logic in
>     'log.py' that was trying to avoid loading the merge_sorted graph.

That would be great. I'd prefer not to do that though until your 
smart-caching is in the core.

> 3) 'time bzr log -n0 -r -10..-1 mysql-6.0' is
>     2.312s =>  0.959s

> 5) 'time bzr log -n0 -r -100..-1 emacs'
>     3.890s =>  0.784s

Sweet. Very well done!

> Anyway, with the current results, I'm pretty sure I've proven
> 'proof-of-concept'.

Indeed.

> There is still some polishing and edge-case work to do. However, I think
> it has at least shown what I hoped to show.

In terms of polish, I think we need to get things to the point where a 
single configuration settings controls whether the cache is used or not. 
In other words, I'd like to see the 'create-history-db' step disappear 
and become implicit.

Sorry if you've explained this already but what's the plan from here wrt 
storage technology: stick with a generic db or move to custom files?

Ian C.