[PATCH 1 of 2] parsers: incrementally parse the revlog index in C

Bryan O'Sullivan bos at serpentine.com
Wed Apr 4 18:58:24 UTC 2012


On Thu, Mar 29, 2012 at 12:51 PM, Matt Mackall <mpm at selenic.com> wrote:

> If I pop the changeset without recompiling, I get this:
>
>  abort: index 00changelog.i is corrupted!
>
> ..which is a big headache for bisecting.


I updated the patch to avoid this. It now returns a tuple with the
same shape as the old parse_index2.

>
> - quick index loads for large indexes are, as predicted, massively
> faster
> - retrieving individual entries after load is 5x SLOWER


The cache that I added seems to have alleviated this problem. But just
to be sure, how were you measuring this? I want to be sure I've got
good numbers to report.

perfheads:

unpatched ! wall 0.104354 comb 0.100000 user 0.100000 sys 0.000000 (best of 94)
  patched ! wall 0.110689 comb 0.110000 user 0.110000 sys 0.000000 (best of 89)

perftags:

unpatched ! wall 0.305407 comb 0.310000 user 0.230000 sys 0.080000 (best of 32)
  patched ! wall 0.017454 comb 0.010000 user 0.000000 sys 0.010000 (best of 149)

> - verify is a few percent slower, presumably because it builds the same
> entries repeatedly

With the cache, there is no longer a measurable difference between
times with/without the refreshed patch.

I'm waiting for blessing from Facebook legal before I "officially"
submit the patch, but it's otherwise good to go.



More information about the Mercurial-devel mailing list