Patchwork [3,of,3] rebase: use matcher to optimize manifestmerge

login
register
mail settings
Submitter Durham Goode
Date March 19, 2017, 7 p.m.
Message ID <800c452bf1a44f9f8171.1489950058@dev111.prn1.facebook.com>
Download mbox | patch
Permalink /patch/19463/
State Accepted
Headers show

Comments

Durham Goode - March 19, 2017, 7 p.m.
# HG changeset patch
# User Durham Goode <durham@fb.com>
# Date 1489949694 25200
#      Sun Mar 19 11:54:54 2017 -0700
# Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
# Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
rebase: use matcher to optimize manifestmerge

The old merge code would call manifestmerge and calculate the complete diff
between the source to the destination. In many cases, like rebase, the vast
majority of differences between the source and destination are irrelevant
because they are differences between the destination and the common ancestor
only, and therefore don't affect the merge. Since most actions are 'keep', all
the effort to compute them is wasted.

Instead, let's compute the difference between the source and the common ancestor
and only perform the diff of those files against the merge destination. When
using treemanifest, this lets us avoid loading almost the entire tree when
rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
commits by 20x.

In mozilla-central, without treemanifest, when rebasing a commit from
default~100000 to default, this speeds up the manifestmerge step from 2.6s to
1.2s.  However, the additional diff adds an overhead to all manifestmerge calls,
especially for flat manifests. When rebasing a commit from default~1 to default
it appears to add 100ms in mozilla-central. While we could put this optimization
behind a flag, I think the fact that it makes merge O(number of changes being
applied) instead of O(number of changes between X and Y) justifies it.
Yuya Nishihara - March 20, 2017, 8:14 a.m.
On Sun, 19 Mar 2017 12:00:58 -0700, Durham Goode wrote:
> # HG changeset patch
> # User Durham Goode <durham@fb.com>
> # Date 1489949694 25200
> #      Sun Mar 19 11:54:54 2017 -0700
> # Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
> # Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
> rebase: use matcher to optimize manifestmerge
> 
> The old merge code would call manifestmerge and calculate the complete diff
> between the source to the destination. In many cases, like rebase, the vast
> majority of differences between the source and destination are irrelevant
> because they are differences between the destination and the common ancestor
> only, and therefore don't affect the merge. Since most actions are 'keep', all
> the effort to compute them is wasted.
> 
> Instead, let's compute the difference between the source and the common ancestor
> and only perform the diff of those files against the merge destination. When
> using treemanifest, this lets us avoid loading almost the entire tree when
> rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
> commits by 20x.

Looks generally good to me, but this needs more eyes.

> @@ -819,6 +819,27 @@ def manifestmerge(repo, wctx, p2, pa, br
>          if any(wctx.sub(s).dirty() for s in wctx.substate):
>              m1['.hgsubstate'] = modifiednodeid
>  
> +    # Don't use m2-vs-ma optimization if:
> +    # - ma is the same as m1 or m2, which we're just going to diff again later
> +    # - The matcher is set already, so we can't override it
> +    # - The caller specifically asks for a full diff, which is useful during bid
> +    #   merge.
> +    if (pa not in ([wctx, p2] + wctx.parents()) and
> +        matcher is None and not forcefulldiff):

Is this optimization better for normal merge where m2 might be far from m1?

> +        # Identify which files are relevant to the merge, so we can limit the
> +        # total m1-vs-m2 diff to just those files. This has significant
> +        # performance benefits in large repositories.
> +        relevantfiles = set(ma.diff(m2).keys())
> +
> +        # For copied and moved files, we need to add the source file too.
> +        for copykey, copyvalue in copy.iteritems():
> +            if copyvalue in relevantfiles:
> +                relevantfiles.add(copykey)
> +        for movedirkey in movewithdir.iterkeys():
> +            relevantfiles.add(movedirkey)
> +        matcher = matchmod.match(repo.root, '',
> +                                 ('path:%s' % p for p in relevantfiles))

Perhaps we can use scmutil.matchfiles(). patterns shouldn't be a generator
since it may be evaluated as a boolean.
Durham Goode - March 21, 2017, 12:14 a.m.
On 3/20/17 1:14 AM, Yuya Nishihara wrote:
> On Sun, 19 Mar 2017 12:00:58 -0700, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham@fb.com>
>> # Date 1489949694 25200
>> #      Sun Mar 19 11:54:54 2017 -0700
>> # Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
>> # Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
>> rebase: use matcher to optimize manifestmerge
>>
>> The old merge code would call manifestmerge and calculate the complete diff
>> between the source to the destination. In many cases, like rebase, the vast
>> majority of differences between the source and destination are irrelevant
>> because they are differences between the destination and the common ancestor
>> only, and therefore don't affect the merge. Since most actions are 'keep', all
>> the effort to compute them is wasted.
>>
>> Instead, let's compute the difference between the source and the common ancestor
>> and only perform the diff of those files against the merge destination. When
>> using treemanifest, this lets us avoid loading almost the entire tree when
>> rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
>> commits by 20x.
>
> Looks generally good to me, but this needs more eyes.
>
>> @@ -819,6 +819,27 @@ def manifestmerge(repo, wctx, p2, pa, br
>>          if any(wctx.sub(s).dirty() for s in wctx.substate):
>>              m1['.hgsubstate'] = modifiednodeid
>>
>> +    # Don't use m2-vs-ma optimization if:
>> +    # - ma is the same as m1 or m2, which we're just going to diff again later
>> +    # - The matcher is set already, so we can't override it
>> +    # - The caller specifically asks for a full diff, which is useful during bid
>> +    #   merge.
>> +    if (pa not in ([wctx, p2] + wctx.parents()) and
>> +        matcher is None and not forcefulldiff):
>
> Is this optimization better for normal merge where m2 might be far from m1?

I'm not sure what you mean by 'normal merge'.  You mean like an 'hg 
merge'?  Or like an hg update?  Any merge where you are merging in a 
small branch will benefit from this (like hg up @ && hg merge 
myfeaturebranch).  Linear hg updates (where m1/m2 are 
ancestors/descendants) won't benefit because the m2-vs-ma optimization 
is the same m2-vs-m1 diff we're doing normally.

>> +        # Identify which files are relevant to the merge, so we can limit the
>> +        # total m1-vs-m2 diff to just those files. This has significant
>> +        # performance benefits in large repositories.
>> +        relevantfiles = set(ma.diff(m2).keys())
>> +
>> +        # For copied and moved files, we need to add the source file too.
>> +        for copykey, copyvalue in copy.iteritems():
>> +            if copyvalue in relevantfiles:
>> +                relevantfiles.add(copykey)
>> +        for movedirkey in movewithdir.iterkeys():
>> +            relevantfiles.add(movedirkey)
>> +        matcher = matchmod.match(repo.root, '',
>> +                                 ('path:%s' % p for p in relevantfiles))
>
> Perhaps we can use scmutil.matchfiles(). patterns shouldn't be a generator
> since it may be evaluated as a boolean.

That sounds like a good idea.  Will put that in V2 after everyone has 
had a say on V1.
Yuya Nishihara - March 21, 2017, 1:29 a.m.
On Mon, 20 Mar 2017 17:14:38 -0700, Durham Goode wrote:
> On 3/20/17 1:14 AM, Yuya Nishihara wrote:
> > On Sun, 19 Mar 2017 12:00:58 -0700, Durham Goode wrote:
> >> # HG changeset patch
> >> # User Durham Goode <durham@fb.com>
> >> # Date 1489949694 25200
> >> #      Sun Mar 19 11:54:54 2017 -0700
> >> # Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
> >> # Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
> >> rebase: use matcher to optimize manifestmerge
> >>
> >> The old merge code would call manifestmerge and calculate the complete diff
> >> between the source to the destination. In many cases, like rebase, the vast
> >> majority of differences between the source and destination are irrelevant
> >> because they are differences between the destination and the common ancestor
> >> only, and therefore don't affect the merge. Since most actions are 'keep', all
> >> the effort to compute them is wasted.
> >>
> >> Instead, let's compute the difference between the source and the common ancestor
> >> and only perform the diff of those files against the merge destination. When
> >> using treemanifest, this lets us avoid loading almost the entire tree when
> >> rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
> >> commits by 20x.
> >
> > Looks generally good to me, but this needs more eyes.
> >
> >> @@ -819,6 +819,27 @@ def manifestmerge(repo, wctx, p2, pa, br
> >>          if any(wctx.sub(s).dirty() for s in wctx.substate):
> >>              m1['.hgsubstate'] = modifiednodeid
> >>
> >> +    # Don't use m2-vs-ma optimization if:
> >> +    # - ma is the same as m1 or m2, which we're just going to diff again later
> >> +    # - The matcher is set already, so we can't override it
> >> +    # - The caller specifically asks for a full diff, which is useful during bid
> >> +    #   merge.
> >> +    if (pa not in ([wctx, p2] + wctx.parents()) and
> >> +        matcher is None and not forcefulldiff):
> >
> > Is this optimization better for normal merge where m2 might be far from m1?
> 
> I'm not sure what you mean by 'normal merge'.  You mean like an 'hg 
> merge'?  Or like an hg update?  Any merge where you are merging in a 
> small branch will benefit from this (like hg up @ && hg merge 
> myfeaturebranch).

'hg merge'. What I had in mind was 'hg up stable && hg merge default' where
pa::p2 would be likely to be as large as p1:p2.

As for rebase (of non-merge commit), p2.files() might be usable since
p2.p1() == pa.
Durham Goode - March 21, 2017, 2:10 a.m.
On 3/20/17 6:29 PM, Yuya Nishihara wrote:
> On Mon, 20 Mar 2017 17:14:38 -0700, Durham Goode wrote:
>> On 3/20/17 1:14 AM, Yuya Nishihara wrote:
>>> On Sun, 19 Mar 2017 12:00:58 -0700, Durham Goode wrote:
>>>> # HG changeset patch
>>>> # User Durham Goode <durham@fb.com>
>>>> # Date 1489949694 25200
>>>> #      Sun Mar 19 11:54:54 2017 -0700
>>>> # Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
>>>> # Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
>>>> rebase: use matcher to optimize manifestmerge
>>>>
>>>> The old merge code would call manifestmerge and calculate the complete diff
>>>> between the source to the destination. In many cases, like rebase, the vast
>>>> majority of differences between the source and destination are irrelevant
>>>> because they are differences between the destination and the common ancestor
>>>> only, and therefore don't affect the merge. Since most actions are 'keep', all
>>>> the effort to compute them is wasted.
>>>>
>>>> Instead, let's compute the difference between the source and the common ancestor
>>>> and only perform the diff of those files against the merge destination. When
>>>> using treemanifest, this lets us avoid loading almost the entire tree when
>>>> rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
>>>> commits by 20x.
>>>
>>> Looks generally good to me, but this needs more eyes.
>>>
>>>> @@ -819,6 +819,27 @@ def manifestmerge(repo, wctx, p2, pa, br
>>>>          if any(wctx.sub(s).dirty() for s in wctx.substate):
>>>>              m1['.hgsubstate'] = modifiednodeid
>>>>
>>>> +    # Don't use m2-vs-ma optimization if:
>>>> +    # - ma is the same as m1 or m2, which we're just going to diff again later
>>>> +    # - The matcher is set already, so we can't override it
>>>> +    # - The caller specifically asks for a full diff, which is useful during bid
>>>> +    #   merge.
>>>> +    if (pa not in ([wctx, p2] + wctx.parents()) and
>>>> +        matcher is None and not forcefulldiff):
>>>
>>> Is this optimization better for normal merge where m2 might be far from m1?
>>
>> I'm not sure what you mean by 'normal merge'.  You mean like an 'hg
>> merge'?  Or like an hg update?  Any merge where you are merging in a
>> small branch will benefit from this (like hg up @ && hg merge
>> myfeaturebranch).
>
> 'hg merge'. What I had in mind was 'hg up stable && hg merge default' where
> pa::p2 would be likely to be as large as p1:p2.

In that case, it may not save any time, but the time would still be 
O(number of incoming changes).

> As for rebase (of non-merge commit), p2.files() might be usable since
> p2.p1() == pa.

Yea, that might be a potential optimization if p2.p1() == pa.  I'm 
hesitant to trust the commit files() list though, but maybe I'm overly 
cautious.
Yuya Nishihara - March 21, 2017, 2:36 p.m.
On Mon, 20 Mar 2017 19:10:08 -0700, Durham Goode wrote:
> On 3/20/17 6:29 PM, Yuya Nishihara wrote:
> > On Mon, 20 Mar 2017 17:14:38 -0700, Durham Goode wrote:
> >> On 3/20/17 1:14 AM, Yuya Nishihara wrote:
> >>> On Sun, 19 Mar 2017 12:00:58 -0700, Durham Goode wrote:
> >>>> # HG changeset patch
> >>>> # User Durham Goode <durham@fb.com>
> >>>> # Date 1489949694 25200
> >>>> #      Sun Mar 19 11:54:54 2017 -0700
> >>>> # Node ID 800c452bf1a44f9f817174c69443121f4ed4c3b8
> >>>> # Parent  d598e42fa629195ecf43f438b71603df9fb66d6d
> >>>> rebase: use matcher to optimize manifestmerge
> >>>>
> >>>> The old merge code would call manifestmerge and calculate the complete diff
> >>>> between the source to the destination. In many cases, like rebase, the vast
> >>>> majority of differences between the source and destination are irrelevant
> >>>> because they are differences between the destination and the common ancestor
> >>>> only, and therefore don't affect the merge. Since most actions are 'keep', all
> >>>> the effort to compute them is wasted.
> >>>>
> >>>> Instead, let's compute the difference between the source and the common ancestor
> >>>> and only perform the diff of those files against the merge destination. When
> >>>> using treemanifest, this lets us avoid loading almost the entire tree when
> >>>> rebasing from a very old ancestor. This speeds up rebase of an old stack of 27
> >>>> commits by 20x.
> >>>
> >>> Looks generally good to me, but this needs more eyes.
> >>>
> >>>> @@ -819,6 +819,27 @@ def manifestmerge(repo, wctx, p2, pa, br
> >>>>          if any(wctx.sub(s).dirty() for s in wctx.substate):
> >>>>              m1['.hgsubstate'] = modifiednodeid
> >>>>
> >>>> +    # Don't use m2-vs-ma optimization if:
> >>>> +    # - ma is the same as m1 or m2, which we're just going to diff again later
> >>>> +    # - The matcher is set already, so we can't override it
> >>>> +    # - The caller specifically asks for a full diff, which is useful during bid
> >>>> +    #   merge.
> >>>> +    if (pa not in ([wctx, p2] + wctx.parents()) and
> >>>> +        matcher is None and not forcefulldiff):
> >>>
> >>> Is this optimization better for normal merge where m2 might be far from m1?
> >>
> >> I'm not sure what you mean by 'normal merge'.  You mean like an 'hg
> >> merge'?  Or like an hg update?  Any merge where you are merging in a
> >> small branch will benefit from this (like hg up @ && hg merge
> >> myfeaturebranch).
> >
> > 'hg merge'. What I had in mind was 'hg up stable && hg merge default' where
> > pa::p2 would be likely to be as large as p1:p2.
> 
> In that case, it may not save any time, but the time would still be 
> O(number of incoming changes).

Right, that wouldn't be a reason to avoid m2-vs-ma optimization.

Patch

diff --git a/mercurial/merge.py b/mercurial/merge.py
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -784,7 +784,7 @@  def driverconclude(repo, ms, wctx, label
     return True
 
 def manifestmerge(repo, wctx, p2, pa, branchmerge, force, matcher,
-                  acceptremote, followcopies):
+                  acceptremote, followcopies, forcefulldiff=False):
     """
     Merge wctx and p2 with ancestor pa and generate merge action list
 
@@ -819,6 +819,27 @@  def manifestmerge(repo, wctx, p2, pa, br
         if any(wctx.sub(s).dirty() for s in wctx.substate):
             m1['.hgsubstate'] = modifiednodeid
 
+    # Don't use m2-vs-ma optimization if:
+    # - ma is the same as m1 or m2, which we're just going to diff again later
+    # - The matcher is set already, so we can't override it
+    # - The caller specifically asks for a full diff, which is useful during bid
+    #   merge.
+    if (pa not in ([wctx, p2] + wctx.parents()) and
+        matcher is None and not forcefulldiff):
+        # Identify which files are relevant to the merge, so we can limit the
+        # total m1-vs-m2 diff to just those files. This has significant
+        # performance benefits in large repositories.
+        relevantfiles = set(ma.diff(m2).keys())
+
+        # For copied and moved files, we need to add the source file too.
+        for copykey, copyvalue in copy.iteritems():
+            if copyvalue in relevantfiles:
+                relevantfiles.add(copykey)
+        for movedirkey in movewithdir.iterkeys():
+            relevantfiles.add(movedirkey)
+        matcher = matchmod.match(repo.root, '',
+                                 ('path:%s' % p for p in relevantfiles))
+
     diff = m1.diff(m2, match=matcher)
 
     if matcher is None:
@@ -972,7 +993,7 @@  def calculateupdates(repo, wctx, mctx, a
             repo.ui.note(_('\ncalculating bids for ancestor %s\n') % ancestor)
             actions, diverge1, renamedelete1 = manifestmerge(
                 repo, wctx, mctx, ancestor, branchmerge, force, matcher,
-                acceptremote, followcopies)
+                acceptremote, followcopies, forcefulldiff=True)
             _checkunknownfiles(repo, wctx, mctx, force, actions, mergeforce)
 
             # Track the shortest set of warning on the theory that bid
diff --git a/tests/test-graft.t b/tests/test-graft.t
--- a/tests/test-graft.t
+++ b/tests/test-graft.t
@@ -186,7 +186,6 @@  Graft out of order, skipping a merge and
    ancestor: 4c60f11aa304, local: 6b9e5368ca4e+, remote: 97f8bfe72746
    e: remote is newer -> g
   getting e
-   b: remote unchanged -> k
   committing files:
   e
   committing manifest
@@ -203,7 +202,6 @@  Graft out of order, skipping a merge and
    preserving e for resolve of e
    d: remote is newer -> g
   getting d
-   b: remote unchanged -> k
    e: versions differ -> m (premerge)
   picked tool ':merge' for e (binary False symlink False changedelete False)
   merging e
diff --git a/tests/test-issue672.t b/tests/test-issue672.t
--- a/tests/test-issue672.t
+++ b/tests/test-issue672.t
@@ -38,7 +38,6 @@  https://bz.mercurial-scm.org/672
   removing 1
    1a: remote created -> g
   getting 1a
-   2: remote unchanged -> k
   1 files updated, 0 files merged, 1 files removed, 0 files unresolved
   (branch merge, don't forget to commit)
 
diff --git a/tests/test-rename-merge2.t b/tests/test-rename-merge2.t
--- a/tests/test-rename-merge2.t
+++ b/tests/test-rename-merge2.t
@@ -89,7 +89,6 @@  args:
    preserving a for resolve of b
    preserving rev for resolve of rev
   starting 4 threads for background file closing (?)
-   a: remote unchanged -> k
    b: remote copied from a -> m (premerge)
   picked tool 'python ../merge' for b (binary False symlink False changedelete False)
   merging a and b to b
@@ -652,7 +651,6 @@  m "um a c" "um x c" "      " "10 do merg
    preserving b for resolve of b
    preserving rev for resolve of rev
   starting 4 threads for background file closing (?)
-   a: remote unchanged -> k
    b: both created -> m (premerge)
   picked tool 'python ../merge' for b (binary False symlink False changedelete False)
   merging b