[MERGE] faster log

[Ian Clatworthy]

Ian Clatworthy wrote:

> Here's a new patch with a tweak to make incremental file
> logging much faster (now 2.0 seconds). In fact, all the
> "recent" (log -r-10..) tasks now complete in 0.2 to 2.2
> seconds. The 10 second drop was because -r10.. was
> loading all of history in the process of calculating
> the revision range! (FWIW, -r-10..-1 doesn't.)

> I'll post a new set of matching figures later today

and then separately ...

> The main one that stands out to me still is LogMergeRevision,
> i.e. showing a single revision off the mainline. (For the Emacs
> repository used, the magic revno tested was 77537.1.3262.)
> The bzr-revnocache plugin I hacked together yesterday greatly
> improves this but it's still slower than I expect.

> Action                                         bzr   bzr-log
> LogTip:top                                     0.2       0.2
> LogTip:top-delta                               0.5       0.5
> LogTip:merges                                 15.7       0.2
> LogTip:merges-delta                           16.1       0.5
> LogMergeRevision:top                          34.8      23.9
> LogMergeRevision:top-delta                    34.6      25.2
> LogMergeRevision:merges                       34.1      23.8
> LogMergeRevision:merges-delta                 35.0      24.5

The latest attached patch fixes this issue by using the new
smarter revid <=> revno mapping routines proposed for Branch
in another patch. I haven't re-benchmarked on my desktop but
I'm seeing roughly a 50% improvement on my laptop for

  log --short -rx.y.z

without bzr-revnocache.

When used in combination with bzr-revnocache, the time taken
is around 3 seconds now of which 0.4 is initialisation and
2.2 is loading the revno cache. That latter time can be
improved heaps by implementing the mergeline cache I'm
considering for revnocache (and/or replacing the flat file
with a btree) but that's another semi-independent story.

Reviewers, the patch includes the revid <=> revno API changes
and the tests for it. Those changes are up for review separately
so can be ignored while reviewing this patch if you wish.

The next step in making log fast is to delegate the sorting
layer to the proposed Branch.iter_merge_revisions() API.
I *could* monkeypatch log.get_view_revisions() in
bzr-revnocache to use the cached merge-sorted graph it
now supports but:

* I'd rather do it properly so all code using the new
  API benefits

* log.get_view_revisions() is a crap API I want to deprecate
  so I don't want to make my plugin depend on it's existence.

Ian C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-refactor-4.patch
Type: text/x-diff
Size: 59492 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090122/b87b8ecf/attachment-0001.bin