Development of a performance tracking tool for Mercurial

[Matt Mackall]

On Mon, 2016-04-18 at 12:22 +0900, FUJIWARA Katsunori wrote:
> At Tue, 12 Apr 2016 18:18:52 -0500,
> Matt Mackall wrote:
> > 
> > 
> > On Tue, 2016-04-12 at 12:03 +0200, Philippe Pepiot wrote:
> > > 
> > > Hello,
> > > 
> > > I published a new demo with parametrized benchmarks: 
> > > https://hg.logilab.org/review/hgperf/raw-file/685dfc2bbe87/html/index.html
> > This regression looks interesting:
> > 
> > https://hg.logilab.org/review/hgperf/raw-file/685dfc2bbe87/html/index.html#o
> > thers.time_tags?branch=default&x=28265&idx=2
>  
> Explicit assignment to "repo.changelog" in perftags() causes this
> regression.
> 
>     https://www.selenic.com/hg/file/1f277ae29168/contrib/perf.py#l158
> 
> This assignment replaces changelog of UNFILTERED repo via
> repofilecache.__set__().
> 
> After 332926212ef8, changelog cache of repoview is always
> (re)calculated at each repetitions in "perftags" benchmark, because
> this replacing causes "cl.index is not unfiindex" and it makes
> repoview recognize "cached changelog might contain garbage, so it
> should be discarded".
> 
> If "perftags" is used to measure cost of "repo.tags()" without any
> caching (explicit assignment above and discarding tags cache at each
> repetitions seems to be executed for this purpose), current benchmark
> result is more realistic than one before 332926212ef8, IMHO.
> 
> Costs measured by perftags before and after 332926212ef8:
> 
>   ====== ===== =================================================
>   before after cost
>   ====== ===== =================================================
>     o     o    instantiate unfiltered repo.changelog
>     x     o    calculate repoview.changelog cache
>     o     o    instantiate repo.manifest
>     o     o    get list of (valid) tags
>   ====== ===== =================================================
> 
> Or should we avoid calculating repoview.changelog cache at each
> repetitions, like as before 332926212ef8 ?

The goal of the two assignments in perf.py is to get closer to the real cost of
a normal "hg tags" call without caching the previous calls. So I suppose
including the cost of building the repoview in there is reasonable.

The overhead of repoview is significant.. and also not directly measured
anywhere that I know of.

-- 
Mathematics is the supreme nostalgia of our time.