[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