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

Jun Wu quark at fb.com
Tue Jun 6 13:35:51 EDT 2017


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.

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


More information about the Mercurial-devel mailing list