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

[Matt Mackall]

On Sat, 2015-03-21 at 11:30 -0700, Gregory Szorc wrote:
> 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.

Ok, thanks. My suspicion is we're going to want to make something that
explicitly follows the pattern of the new revbranchcache.. once that's
stabilized.

-- 
Mathematics is the supreme nostalgia of our time.