[PATCH 3 of 7] context.status: move manifest caching trick to _buildstatus()
pierre-yves.david at ens-lyon.org
Mon Nov 10 18:23:47 CST 2014
On 11/10/2014 10:55 PM, Martin von Zweigbergk wrote:
> On Mon Nov 10 2014 at 2:33:57 PM Matt Mackall <mpm at selenic.com
> <mailto: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 <mailto:sean.michael.farley at gmail.com>__>
> > wrote:
> > >
> > > Martin von Zweigbergk writes:
> > >
> > > > # HG changeset patch
> > > > # User Martin von Zweigbergk <martinvonz at gmail.com
> <mailto:martinvonz at gmail.com>>
> > > > # Date 1413097213 25200
> > > > # Sun Oct 12 00:00:13 2014 -0700
> > > > # Branch stable
> > > > # Node ID ada8ab4086be7814622374c04aa5ab__6c94deacb2
> > > > # Parent 3776f277e512ecdc5b2da73f3f3264__af3e173640
> > > > context.status: move manifest caching trick to _buildstatus()
> > > >
> > > > In basectx._buildstatus(), we read the manifests for the two
> > > > 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.
This should probably end up as a comment in a the code to share the
wisdom with future reader.
More information about the Mercurial-devel