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

[Martin von Zweigbergk]

On Tue, Jun 6, 2017 at 10:35 AM, Jun Wu <quark at fb.com> wrote:
> Excerpts from Martin von Zweigbergk's message of 2017-06-06 10:01:34 -0700:
>> 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}' |         |          |           |
>
> Note this is a repo with a small len(changelog) and I think cache rebuilding
> time matters. Other parts of Mercurial are friendly to large len(changelog),
> I think it's better to not break that property.

Yes, that's a fair point. I considered timing cache rebuilding as
well, but I didn't get to it.

>
>> 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?
>> [...]