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

Martin von Zweigbergk martinvonz at google.com
Mon Nov 10 18:38:07 CST 2014


Sounds good to me. I think you're the one who picked up this series. Do you
want me to resend?

On Mon Nov 10 2014 at 4:24:04 PM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141111/08486841/attachment.html>


More information about the Mercurial-devel mailing list