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

[Matt Mackall]

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.

-- 
Mathematics is the supreme nostalgia of our time.