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

Jun Wu quark at fb.com
Thu Jun 1 18:28:19 EDT 2017


Excerpts from Sean Farley's message of 2017-06-01 13:27:44 -0700:
> > Both series are complementary and useful. Obscache is very efficient for 
> > its purpose and the other one improve other aspect of evolution related 
> > computation. We already have many rev indexed caches so nothing really 
> > new here.
> 
> This was my thinking as well. Though, I'm not trying to muddy the waters
> here.

There are 4 revsets: obsolete, unstable, bumped, and divergent. My patch
speeds up all of them significantly while obscache only speeds up the first
one.

I admit that obscache is slightly faster than indexing on the "obsolete"
revset. But that perf difference would be like just 20ms for hg-committed. I
think that 20ms does not justify the complexity of a complete
(huge-repo-friendly) implementation obscache and the coupling with revision
number in design. And I do think eventually we want the related revset to be
lazy so there won't be noticeable perf difference.

That said, I think obsstore "cachekey" could be useful to help remove
"hash(filteredrevs)" and allow us to remove iterating filteredrevs to be
able to finally make related revset lazy.



> > The potential scaling issue on large repository of the obscache are easy 
> > to overcome, I've a series fixing most of them already ready to be sent 
> > once that one is in.
> 
> Ah, are those online somewhere?
> 
> > I would be happy to join a VC to discuss this.
> 
> I might like to join but if the schedule doesn't work out, please move
> ahead without me.


More information about the Mercurial-devel mailing list