[PATCH STABLE v2] tags: create a supplemental cache of .hgtags filenodes (issue4550)

[Gregory Szorc]

On Fri, Mar 20, 2015 at 12:08 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Thu, 2015-03-19 at 20:50 -0700, Gregory Szorc wrote:
> > On Tue, Mar 17, 2015 at 2:36 PM, Matt Mackall <mpm at selenic.com> wrote:
> >
> > > On Mon, 2015-03-16 at 23:08 -0700, Gregory Szorc wrote:
> > > > # HG changeset patch
> > > > # User Gregory Szorc <gregory.szorc at gmail.com>
> > > > # Date 1426392860 25200
> > > > #      Sat Mar 14 21:14:20 2015 -0700
> > > > # Branch stable
> > > > # Node ID 9e0d583a15c42f11d06b66684c9c9d85d9269d9f
> > > > # Parent  b73a22d1d9bfe3a7f8633340ea75a0ab1526c21b
> > > > tags: create a supplemental cache of .hgtags filenodes (issue4550)
> > >
> > > The _only_ thing that makes this proposal appropriate for stable is
> that
> > > it fights a performance regression.
> > >
> > > Everything else about it screams not appropriate for stable. Especially
> > > the part where it grows without bounds. People in the real world often
> > > run the same hg -for years- and if they install this on a server, they
> > > could have a 1-to-1 ratio of cache entries to changelog entries.
> > >
> > > But this is also the first time I've seen the ALARMING numbers related
> > > to this bug, which is why I haven't been paying much attention.
> > > Specifically, they're not in your bug report ("dozens of seconds" with
> > > no baseline), which you self-triaged without cc:ing any guilty parties
> > > and thus slipped entirely past my radar.
> > >
> > > Have you actually identified the problematic change in 3.3? Can we back
> > > it out?
> > >
> > > I'm still tempted to re-release 3.2.4 as 3.3.x due to the number of
> > > untended regressions.
> >
> >
> > I posted some numbers to the bug last night. I have not yet identified a
> > regression range. In fact, I /think/ the evolve extension might have
> > regressed (passing an unfiltered repo to something that reads tags).
> >
> > I think you've talked me out of trying to land this in stable.
> >
> > What do I need to change for this to land in default?
>
> [resend]
>
> I'm still struggling to follow the story here, because the discussion is
> spread out over weeks and I've got dozens of things I'm trying to pay
> attention to. What I've gathered so far: there's a regression in tags
> computation caused by alternating between filtered and unfiltered views
> but we don't know when it was introduced or why.
>
> I'm not even sure if this is connected to the cset that got backed out
> anymore as there's no explicity link between it and the bug report and I
> have the attention span of a goldfish. Halp.
>
> Since I still don't know what introduced the problem, so I'm going to be
> super-reluctant to accept new and nontrivial code to fix it until
> someone says "this changeset caused the problem and we can't go back
> because <reasons> and we can't fix it because <reasons>". Can I please
> get you to focus on the first clause of that statement? Writing code
> before that point is way premature.


I've updated issue 4550 with my findings. AFAICT this is an outstanding
issue. I accidentally flagged it as a regression because I converted my
local repo to generaldelta around the time of 3.3, which made manifest
resolution slower (longer delta chains), making my tags cache population
times increase by a few minutes, causing me to suspect a regression in 3.3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150321/edc60383/attachment.html>