[PATCH STABLE V2] hgweb: cache fctx.parents() in annotate command (issue5414)

[Gregory Szorc]

On Mon, Nov 7, 2016 at 4:42 AM, Yuya Nishihara <yuya at tcha.org> wrote:

> On Sun, 6 Nov 2016 17:01:05 +0000, Jun Wu wrote:
> > Excerpts from Yuya Nishihara's message of 2016-11-06 11:31:04 +0900:
> > > Perhaps fctx.parents() can be property-cached, but we'll need to drop
> > > uninteresting chains of parents in fctx.annotate().
> >
> > If we go the property-cache approach, I think it's better to cache
> > "_adjustedlinkrev". It's at a lower level and covers both "parents"
> > and "introrev". Caching "parents" may increase memory usage
> unintentionally.
> >
> > I don't fully get what "uninteresting chains of parents" means here.
> > In the annotate case, let's say f1, f2 = f0.parents().
> > Both f1 and f2 have _descendantrev set to f0's adjusted linkrev.
>
> As you said, what's in my mind was the memory usage. Caching fctx.parents()
> would mean annotate() builds a full link from self to root nodes. Some of
> these intermediate nodes aren't useful for hgweb.
>
> > Suppose there is a global cache dict: {(path, filenode, srcrev):
> linkrev}, I
> > think if srcrev=_descendantrev (it's true for f1, f2) and _descendantrev
> is
> > adjusted from the direct child (f0), then it is "interesting" and can be
> > cached. This is similar to what marmoute said during the sprint - for the
> > log -f or annotate case, once the first fctx's introrev is known, the
> cache
> > can be used to calculate the ancestors' adjusted linkrevs.
>
> Given we have ugly hacks to pass ancestry data around fctx objects, a
> global
> cache might be useful.
>

Could we change basefilectx.annotate() to return a rich data structure
instead of a list of tuples? That data structure could have the cached
parents and other reusable cache data (which could be passed into
subsequent calls if needed).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161107/20e0b62d/attachment-0002.html>