[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