On 11/9/20 12:13 PM, Elijah Newren wrote:> Actually, this was pretty enlightening. I think I know about what's > happening... > > First, a few years ago, Ben said that merges in the Microsoft repos > took about an hour[1]: > "For the repro that I have been using this drops the merge time from ~1 hour to > ~5 minutes and the unmerged entries goes down from ~40,000 to 1." > The change he made to drop it that far was to turn off rename detection. > > [1] https://lore.kernel.org/git/20180426205202.23056-1-benpeart@xxxxxxxxxxxxx/ > > Keep that in mind, especially since your times are actually > significantly less than 5 minutes... Yes, the other thing to keep in mind is that this is a Scalar repo with the default cone-mode sparse-checkout of only the files at root. For this repo, that means that there are only ~10 files actually present. I wanted to remove any working directory updates/checks from the performance check as possible. >> $ /_git/git/summarize-perf git rebase --onto to from test >> Successfully rebased and updated refs/heads/test. >> Accumulated times: >> 8.511 : <unmeasured> (74.9%) > > Wild guess: This is setup_git_directory() loading your ~3 million entry index. I think there is also some commit walking happening, but it shouldn't be too much. 'from' and 'to' are not very far away. > Did you include two runs of recursive and two runs of ort just to show > that the timings were stable and thus there wasn't warm or cold disk > cache issues affecting things? If so, good plan. (If there was > another reason, let me know; I missed it.) For the rebase, I did "--onto to from test" and "--onto from to test" to show both directions of the rebase. The merge I did twice for the cache issues ;) > .004s on label:incore_nonrecursive -- that's the actual merge > operation. This was a trivial rebase, and the merging took just 4 > milliseconds. But the overall run took 11.442 seconds because working > with 3M+ entries in the index just takes forever, and my code didn't > touch any on-disk formats, certainly not the index format. > > _All_ of my optimization work was on the merging piece, not the stuff > outside. But for what you're testing here, it appears to be > irrelevant compared to the overhead. OK, so since we already disable rename detection through config, the machinery that you are changing is already fast with the old algorithm in these trivial cases. To actually show any benefits, we would need to disable rename detection or use a larger change. >> And here are timings for a simple merge. Two files at root were changed in the >> commits I made, but there are also some larger changes from the commit history. >> These should all be seen as "this tree updated in one of the two, so take that >> tree". > > Ahah! That's a microsoft-specific optimization you guys made in the > recursive strategy, yes? I'm not aware of any logic we have that's different from core Git. The config we use [1] includes "merge.stat = false" and "merge.renames = false" but otherwise seems to be using stock Git. [1] https://github.com/microsoft/scalar/blob/1d7938d2df6921f7a3b4f3f1cce56a00929adc40/Scalar.Common/Maintenance/ConfigStep.cs#L100-L127 I'm CC'ing Jeff Hostetler to see if he knows anything about a custom merge algorithm in microsoft/git. > It does NOT exist in upstream git. It's > also one that is nearly incompatible with rename detection; it turns > out you can only do that optimization in the face of rename detection > if you do a HUGE amount of specialized work and tracking in order to > determine when it's safe _despite_ needing to detect renames. Perhaps merge.renames=false is enough to trigger this logic already? > I > thought that optimization was totally incompatible with rename > detection for a long time; I tried it a couple times while working on > ort and watched it break all kinds of rename tests...but I eventually > discovered some tricks involving a lot of work to be able to run that > optimization. I will try to keep this in mind. > So, you aren't comparing upstream "recursive" to "ort", you're > comparing a tweaked version of recursive, and one that is incompatible > with how recursive's rename detection work. In fact, just to be clear > in case you go looking, I suspect that this tweak is to be found > within unpack_trees.c (which recursive relies on heavily). > > Further, you've set it up so there are only a few files changed after > unpack_trees returns. > > In total, you have: (1) turned off rename detection (most my > optimizations are for improving this factor, meaning I can't show an > advantage), (2) you took advantage of no rename detection to implement > trivial-tree merges (thus killing the main second advantage my > algorithm has), and (3) you are looking at a case with a tiny number > of changes for the merge algorithm to process (thus killing a third > optimization that removes quadratic performance). Those are my three > big optimizations, and you've made them all irrelevant. In fact, > you're in an area I would have been worried that ort would do _worse_ > than recursive. I track an awful lot of things and there is overhead > in checking and filling all that information in; if there are only a > few entries to merge, then all that information was a waste to collect > and ort might be slower than recursive. But then again, that should > be a case where both algorithms are "nearly instantaneous" (or would > be if it weren't for your 3M+ index entry repo causing run_builtin()'s > call to setup_git_directory() in git.c to take a huge amount of time > before the builtin is even called.) Thanks for your time isolating this case. I appreciate knowing exactly which portions of the merge algorithm are being touched and which are not. > 5 seconds. I do have to hand it to Ben and anyone else involved, > though. From 1 hour down to 5 seconds is pretty good, even if it was > done by hacks (turning off rename detection, and then implementing > trivial-tree merging that would have broken rename detection). I > suspect that whoever did that work might have found the unconditional > discarding and re-reading of the index and fixed it as well? As you can probably tell from my general confusion, I had nothing to do with it. ;) > Heh, yeah 0.002 seconds for ..label:incore_recursive. Only 2 > milliseconds to create the actual merge tree. That does suggest you > might have fun with 'git log -p --remerge-diff'; if you can redo > merges in 2 milliseconds, showing them in git log output is very > reasonable. :-) Yeah, 'git merge-tree' is very fast for these cases, so I assumed that something else was going on for that command. > Could we have some fun, though? What if you have some merge or rebase > involving lots of changes, and you turn rename detection back on, and > you disable that trivial-tree resolution optimization that breaks > recursive's rename detection handling...and then compare recursive and > ort? (It might be easiest to just compare upstream recursive rather > than the one with all the microsoft changes to make sure you undid > whatever trivial tree handling work exists.) I can try these kinds of cases, but it won't be today. I'm on kid duty today, and answering emails in between running around with them. > For example, my testcase in the linux kernel was finding a series of a > few dozen patches I could rebase back to an older version, but > tweaking the "older" version by renaming drivers/ -> pilots/ (with > about 26K files under that directory, that meant about 26K renames). > So, I got to see rebasing of dozens of real changes across a massive > rename boundary -- and the massive rename boundary also guaranteed > there were lots of entries for the merge algorithm to deal with. > > In the end, though, 4 milliseconds for the rebase and 2 milliseconds > for the merge, with the rest all being overhead of interfacing to the > index and working tree actually seems pretty good to me. I'm just > curious if we can check how things work for more involved cases. I'm definitely interested in identifying how your algorithm improves over the previous cases, and perhaps re-enabling rename detection for merges is enough of a benefit to justify the new one. Eventually, I hope to actually engage with your patches in the form of review. Just trying to build a mental model for what's going on first. Thanks, -Stolee
