Development of a performance tracking tool for Mercurial

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Sun Apr 17 23:22:12 EDT 2016


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#others.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 ?

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list