Linkrev perf

Durham Goode durham at fb.com
Wed Sep 28 12:23:44 EDT 2016



On 9/28/16 1:18 AM, Jun Wu wrote:
> Excerpts from Durham Goode's message of 2016-09-27 16:29:42 -0700:
>> The map is just there to make the initial step of adjustlinkrev more
>> likely to succeed.  When it scans the changelog.i, it knows of more
>> nodes it can search for.
> This may change the behavior of "_adjustlinkrev" - instead of returning the
> first ancestor satisfying the condition, it may return the second, or the
> third etc.
We could continue the .i scan until we reach the bottom most available 
linkrev, so we could return the earliest one available.
>> commit, rebase, amend, etc can also be filling the cache as commits are
>> added.
> What if the linkrev does not need to be adjusted (i.e. it is unique)? It
> seems it will fallback to the existing slow changelog walk in this case.
> Since unique linkrev is not rare, so I guess this approach does not help
> much.
If it does not need adjustment, the changelog.i walk handles that case 
in a couple milliseconds.  It's the changelog.d walk that we want to 
avoid (where it looks at the contents of each commit), and the 
filectx:[linknodes] cache means the .i case will work in the vast 
majority of cases.
>
> Under the hood, I think it's the same question - cache invalidation - it's
> really hard to mark "this map entry is up-to-date and all the introrevs of
> the fctx is here, so slow changelog walk is unnecessary", vs. "this map
> entry contains just a part of the introrevs, so you still need a slow
> changelog walk".
There are two types of changelog walks.  Walking the .i is fast, walking 
the .d is slow.  I think we need to disambiguate here.  This cache only 
helps with the slow case.


More information about the Mercurial-devel mailing list