[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