[PATCH 1 of 6 V2] obsstore: add a 'cachekey' method
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
There are 4 revsets: obsolete, unstable, bumped, and divergent. My patch
speeds up all of them significantly while obscache only speeds up the first
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