On 7/23/2021 8:54 AM, Elijah Newren via GitGitGadget wrote:
...
> === Basic Optimization idea ===
>
> In this series, I make use of memory pools to get faster allocations and
> deallocations for many data structures that tend to all be deallocated at
> the same time anyway.
Makes sense. This is appropriate for a final optimization, since the gains
tend to be quite small.
> === Results ===
>
> For the testcases mentioned in commit 557ac0350d ("merge-ort: begin
> performance work; instrument with trace2_region_* calls", 2020-10-28), the
> changes in just this series improves the performance as follows:
>
> Before Series After Series
> no-renames: 204.2 ms ± 3.0 ms 198.3 ms ± 2.9 ms
> mega-renames: 1.076 s ± 0.015 s 661.8 ms ± 5.9 ms
> just-one-mega: 364.1 ms ± 7.0 ms 264.6 ms ± 2.5 ms
But these are larger than I anticipated! Amazing.
> === Overall Results across all optimization work ===
I enjoyed reading this section. I'm excited to make ORT the default in
the microsoft/git fork and see how this improves the lives of our users.
> === Caveat ===
>
> It may be worth noting, though, that my optimization numbers above for
> merge-ort use test-tool fast-rebase. git rebase -s ort on the three
> testcases above is 5-20 times slower (taking 3.835s, 6.798s, and 1.235s,
> respectively).
The performance and behavior changes recommended here should definitely
be considered. However, the benefits still apply and at the moment users
do not expect immediate responses from 'git rebase' so we have some time
to approach with caution.
I only had one small question that is not even important to the
correctness of this series, so feel free to ignore it. The patches tell
a convincing story.
Just to be careful, have you taken the time to run the merge-ORT tests
with --valgrind?
Thanks,
-Stolee
