[PATCH] revlog: teach revlog to construct a revision from parentdeltas

[Benoit Boissinot]

On Sun, Aug 08, 2010 at 01:33:44PM +0530, Pradeepkumar Gayam wrote:
> On Sat, Aug 7, 2010 at 8:28 PM, Matt Mackall <mpm at selenic.com> wrote:
> 
> > On Sat, 2010-08-07 at 12:00 +0530, in3xes at gmail.com wrote:
> > > # HG changeset patch
> > > # User Pradeepkumar Gayam <in3xes at gmail.com>
> > > # Date 1281138500 -19800
> > > # Node ID 12a41d114b113af32329386b32d88709c0f28816
> > > # Parent  db0f8a9594be4ecde3c1cc0ba71087997650ca9a
> > > revlog: teach revlog to construct a revision from parentdeltas
> >
> # hg with your patch on delta repo
> > $ time hg -R p2 verify
> > checking changesets
> > checking manifests
> > crosschecking files in changesets and
> > manifests
> > checking files
> > 1555 files, 11766 changesets, 23269 total
> > revisions
> >
> > real    0m49.717s
> > user    0m48.773s
> > sys     0m0.383s
> >
> > In this case, if we debug index of manifest the reason is clear, the
> distance between two base is increasing as it goes new revisions. That
> increases the number of patches to process. Hence decrease in performance.
> We can see this  http://paste.lisp.org/display/111974  The number of patches
> to process increases to 4digit number in the end of the list. I tried
> decreasing distance between bases by inserting full revisions frequently.
> That gave fruitful results but not much encouraging.

My guess would be more in the "fastpath" of verify. It uses
manifest.readdelta() a lot. This is an optimization for tip-delta, but
really not the right thing to do for parent-delta (will probably trigger
a diff computation, which is the exact thing we want to avoid).

Worth investigating.

(actually, I believe the verify code is slightly incorrect, because of
the use of readdelta(). A delta to the parent is better)

Cheers,

Benoit

-- 
:wq