[PATCH 1 of 6 V2] obsstore: add a 'cachekey' method

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Jun 7 10:27:41 EDT 2017


On 06/06/2017 06:01 PM, Martin von Zweigbergk wrote:
> Here are some timings from a hopefully unbiased third party. These are
> best-of-20 times, in seconds. No extensions enabled. I ran
> "debugupdatecaches" before each series of commands to populate the
> caches (I think both obscache and the radixlink cache are hooked into
> that command).
>
>
>                          |  At @   | obscache | radixlink |
> id -r @                  |  0.70   |   0.38   |    0.42   |
> log -r @                 |  1.60   |   1.08   |    0.59   |
> export @                 |  0.71   |   0.33   |    0.59   |
> log -G -r 'draft()'      |  1.19   |   1.22   |    0.74   |
> log -G -r 'draft()' \    |  1.26   |   1.27   |    0.97   |
>   -T '{node} {troubles}' |         |          |           |
>
> We write Mercurial for users, so I've included commands similar to
> what I use somewhat often (plus "hg id" because Pierre-Yves and Jun
> like it).
>
> So radixlink seems to provide a nice speedup across the board. So I
> vote for getting that series in good enough shape to include it and
> then we can come *consider* adding obscache on top after. I know
> Pierre-Yves wanted to get the cachekey and dualsourcecache pieces in
> at least to simplify further work in the evolve extension, but I'm
> very reluctant to add otherwise unused code (more than just a few
> lines) to core for that reason. What do other reviewers think?

I'm not advocating for introducing dead code. The obsstore 
indexes(radix-link) are a cache layer to the obsstore. As a cache, the 
indexes need a cache-key and associated logic for incremental update.

What I need here is to have this logic "standard" and reusable by other 
caches. I can split the obsstore specific part from the changelog part 
and make it available, either used by the obscache or by the indexes

note: current indexes cache key is fragile (file length check only) and 
would benefit from the stronger cachekey+logic) available in this series.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list