[PATCH 3 of 7] context.status: move manifest caching trick to _buildstatus()

[Martin von Zweigbergk]

On Mon Nov 10 2014 at 2:33:57 PM Matt Mackall <mpm at selenic.com> wrote:

> On Mon, 2014-11-03 at 19:02 +0000, Martin von Zweigbergk wrote:
> > On Mon Nov 03 2014 at 10:39:39 AM Sean Farley <
> sean.michael.farley at gmail.com>
> > wrote:
> >
> > >
> > > Martin von Zweigbergk writes:
> > >
> > > > # HG changeset patch
> > > > # User Martin von Zweigbergk <martinvonz at gmail.com>
> > > > # Date 1413097213 25200
> > > > #      Sun Oct 12 00:00:13 2014 -0700
> > > > # Branch stable
> > > > # Node ID ada8ab4086be7814622374c04aa5ab6c94deacb2
> > > > # Parent  3776f277e512ecdc5b2da73f3f3264af3e173640
> > > > context.status: move manifest caching trick to _buildstatus()
> > > >
> > > > In basectx._buildstatus(), we read the manifests for the two
> revisions
> > > > being compared. For "caching reasons" unknown to me,
> > >
> > > If I recall correctly, this "caching reason" was due to reading the
> > > revlog from disk.
> > >
> >
> > Yes, my guess was that it was something about caching while reading the
> > revlog, but thanks for confirming.
>
> More specifically, if you have revisions 1000 and 1001, 1001 is probably
> stored as a delta against 1000. Thus, if you read 1000 first, we'll
> reconstruct 1000 and cache it so that when you read 1001, we just need
> to apply a delta to what's in the cache. So that's one full
> reconstruction + one delta application.
>

I did not think about the delta application overhead. Thanks for explaining.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20141110/6f6e27b3/attachment-0002.html>