view tests/test-revisions.t @ 51108:0250e45040f1

revlog: add a small cache of unfiltered chunk

This can provides a massive boost to the reading of multiple revision and the
computation of a valid delta chain.

This greatly help operation like `hg log --patch`, delta computation (helping
pull/unbundle), linkrev adjustment (helping copy tracing).

A first round of benchmark for `hg log --patch --limit 1000` shows improvement
in the 10-20% range on "small" repository like pypy or mercurial and large
improvements (about 33%) for more complex ones like netbeans and mozilla's.

These speeds up are consistent with the improvement to `hg pull` (from a server
sending poor deltas) I saw benchmarking this last year. Further benchmark will
be run during the freeze.

I added some configuration in the experimental space to be able to further test
the effect of various tuning for now. This feature should fit well in the
"usage/resource profile" configuration that we should land next cycle.

When it does not provides a benefit the overhead of the cache seem to be around
2%, a small price for the big improvement. In addition I believe we could shave
most of this overhead with a more efficent lru implementation.

  $ hg init repo
  $ cd repo

  $ echo 0 > a
  $ hg ci -qAm 0
  $ for i in 5 8 14 43 167; do
  >   hg up -q 0
  >   echo $i > a
  >   hg ci -qm $i
  > done
  $ cat <<EOF >> .hg/hgrc
  > [alias]
  > l = log -T '{rev}:{shortest(node,1)}\n'
  > EOF

  $ hg l
  5:00f
  4:7ba5d
  3:7ba57
  2:72
  1:9
  0:b
  $ cat <<EOF >> .hg/hgrc
  > [experimental]
  > revisions.disambiguatewithin=not 4
  > EOF
  $ hg l
  5:00
  4:7ba5d
  3:7b
  2:72
  1:9
  0:b
9 was unambiguous and still is
  $ hg l -r 9
  1:9
7 was ambiguous and still is
  $ hg l -r 7
  abort: ambiguous revision identifier: 7
  [10]
7b is no longer ambiguous
  $ hg l -r 7b
  3:7b

  $ cd ..