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

[Pierre-Yves David]

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
>     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.


This should probably end up as a comment in a the code to share the 
wisdom with future reader.

-- 
Pierre-Yves David