{"thread":{"id":"56648","subject":"Merge ORT performance in the wild","startedAt":"2021-10-05T19:42:07Z","lastAt":"2021-10-06T15:01:23Z","messageCount":2,"participants":["Derrick Stolee","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"437997","messageId":"9e4411aa-e757-0653-0c2a-24894b13158f@gmail.com","threadId":"56648","inReplyTo":null,"subject":"Merge ORT performance in the wild","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-10-05T19:42:01Z","receivedAt":"2021-10-05T19:42:07Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"Hello all, especially Elijah.\n\nWe finally shipped Git 2.33.0 (with VFS for Git) to the Windows OS\nengineers, and the microsoft/git fork enables the ORT merge strategy\nby default in this version.\n\nI know that we are queued to include the ORT merge strategy as on\nby default in Git 2.34.0, and to further support that change (and\nthank Elijah for working hard on the feature), I wanted to share\nsome early data on our users interacting with it.\n\nWe have about 250 users who have upgraded, relative to ~2,300 users\nwho were active on the previous version. However, we saw sufficiently\nhigh use of 'git cherry-pick' and 'git merge' in these early users to\nshare these results for how they are experiencing the new world:\n\n| Builtin     | Percentile | Recursive | ORT   |\n|-------------|------------|-----------|-------|\n| cherry-pick | 50         |  18.4s    | 14.1s |\n| cherry-pick | 80         |  34.9s    | 15.4s |\n| cherry-pick | 95         | 117.9s    | 17.7s |\n| merge       | 50         |   7.7s    |  1.2s |\n| merge       | 80         |  17.9s    | 12.7s |\n| merge       | 95         |  58.9s    | 22.3s |\n\nThis matches the results from a synthetic performance test I ran\nin our monorepos: ORT is always faster, but its outlier performance\nis far faster than the outlier performance of the 'recursive'\nstrategy.\n\nThanks!\n-Stolee\n"},{"id":"438070","messageId":"CABPp-BF8R-i0CnYE9mQjvwTWuZCgW0VsTTajWTpi15fk9F48Lg@mail.gmail.com","threadId":"56648","inReplyTo":"9e4411aa-e757-0653-0c2a-24894b13158f@gmail.com","subject":"Re: Merge ORT performance in the wild","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-10-06T14:58:41Z","receivedAt":"2021-10-06T15:01:23Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Oct 5, 2021 at 12:42 PM Derrick Stolee <stolee@gmail.com> wrote:\n>\n> Hello all, especially Elijah.\n>\n> We finally shipped Git 2.33.0 (with VFS for Git) to the Windows OS\n> engineers, and the microsoft/git fork enables the ORT merge strategy\n> by default in this version.\n>\n> I know that we are queued to include the ORT merge strategy as on\n> by default in Git 2.34.0, and to further support that change (and\n> thank Elijah for working hard on the feature), I wanted to share\n> some early data on our users interacting with it.\n>\n> We have about 250 users who have upgraded, relative to ~2,300 users\n> who were active on the previous version. However, we saw sufficiently\n> high use of 'git cherry-pick' and 'git merge' in these early users to\n> share these results for how they are experiencing the new world:\n>\n> | Builtin     | Percentile | Recursive | ORT   |\n> |-------------|------------|-----------|-------|\n> | cherry-pick | 50         |  18.4s    | 14.1s |\n> | cherry-pick | 80         |  34.9s    | 15.4s |\n> | cherry-pick | 95         | 117.9s    | 17.7s |\n> | merge       | 50         |   7.7s    |  1.2s |\n> | merge       | 80         |  17.9s    | 12.7s |\n> | merge       | 95         |  58.9s    | 22.3s |\n>\n> This matches the results from a synthetic performance test I ran\n> in our monorepos: ORT is always faster, but its outlier performance\n> is far faster than the outlier performance of the 'recursive'\n> strategy.\n\nGreat news, thanks for sharing.\n\nThis is basically just testing one of the optimizations, too.  I'm\nstill curious what the performance difference would be on your large\nrepositories, comparing git <= v2.30's recursive (i.e. before my\noptimizations, some of which benefitted recursive) with rename\ndetection _not_ turned off, and current ort.  I suspect you'd have a\nhard time convincing users to use the former, though.  IIRC, Ben\nreported one example merge took on the order of an hour, but I don't\nknow which repository that was with or if it even had many renames.\nAnyway, it's nice to know that even without the consideration of\nrename detection in the old comparison numbers, you're still seeing\nnice speedups.\n"}]}