You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
merge-ort, diffcore-rename: employ cached renames when possible
When there are many renames between the old base of a series of commits
and the new base, the way sequencer.c, merge-recursive.c, and
diffcore-rename.c have traditionally split the work resulted in
redetecting the same renames with each and every commit being
transplanted. To address this, the last several commits have been
creating a cache of rename detection results, determining when it was
safe to use such a cache in subsequent merge operations, adding helper
functions, and so on. See the previous half dozen commit messages for
additional discussion of this optimization, particularly the message a
few commits ago entitled "add code to check for whether cached renames
can be reused". This commit finally ties all of that work together,
modifying the merge algorithm to make use of these cached renames.
For the testcases mentioned in commit 557ac03 ("merge-ort: begin
performance work; instrument with trace2_region_* calls", 2020-10-28),
this change improves the performance as follows:
Before After
no-renames: 5.665 s ± 0.129 s 5.624 s ± 0.077 s
mega-renames: 11.435 s ± 0.158 s 10.213 s ± 0.032 s
just-one-mega: 494.2 ms ± 6.1 ms 497.6 ms ± 5.3 ms
Note that this optimization competes with the previous optimizations
(namely full use of exact renames, basename-guided rename detection, and
detecting when we can skip detecting renames for certain paths and still
get the same result); if it were not for those previous optimizations,
this optimization would have sped up the mega-renames testcase by a
factor of nearly 35. (The factor of 35 comes from the fact that the
mega-renames testcase involves rebasing 35 commits, and each one
essentially involves detecting the same renames.) So, while the
improvement seen here is modest at best, keep in mind that this
optimization kicks in to help accelerate cases where the previous
optimizations do not apply, so there may be other testcases where this
optimization helps more.
The changes made in this optimization also lay some important groundwork
for a future optimization around having collect_merge_info() avoid
recursing into subtrees in more cases.
Signed-off-by: Elijah Newren <[email protected]>
0 commit comments