[PATCH 1 of 6 V2] obsstore: add a 'cachekey' method
Jun Wu
quark at fb.com
Mon Jun 5 05:05:57 UTC 2017
Excerpts from Pierre-Yves David's message of 2017-06-04 01:24:59 +0200:
> There is likely something wrong with your timing is you get a 10ms speed
> up… since the obscache computation is about 1ms. How are you running
> your testing? Do you have your code available somewhere?
>
> (note: you probably have an outdated version on obscache too, I shaved
> it a bit in the past week (1.58ms → 0.95ms))
Since I have sent the complete version of radixlink series, I'd like to
comment on (re-clarify) some key points:
1. obscache puts Facebook at risk of spending about 10 seconds for a
simple command like "hg id", even if the obsstore is tiny.
That could happen when obscache needs to be rebuilt. Like after a fresh
clone, after a real strip (histedit --abort does a real strip).
radixlink does not have such issue - without a prebuilt index, it's
even a bit faster than what we have today.
2. radixlink speeds up all 4 revsets (obsolete, unstable, bumped,
divergent), while obscache only works for obsolete.
I admit it could be 20ms slower for the "obsolete" set. But if I really
want to work in this area, I believe I can catch up by implementing
efficient laziness (that also applies to other 3 sets).
3. Looking at the future where hash-preserving obsstore is a thing,
radixlink is compatible with it out-of-box. obscache has to be reworked
to support it.
I think there is little reason that we want the obscache series. I hope
someone from the committee could see through and make the right decision.
> [...]
More information about the Mercurial-devel
mailing list