On Wed, Jul 14, 2021 at 01:12:33AM +0000, Elijah Newren via GitGitGadget wrote: > The combined effect of the above is that the file size used in past > calculations was likely about 5x too large. Combine that with a CPU > performance improvement of ~30%, and we can increase the limits by > a factor of sqrt(5/(1-.3)) = 2.67, while keeping the original stated > time limits. It's slightly sad that we only got a 30% CPU improvement in the past 10 years. Are you just counting clock speed as a short-hand here? I think that doesn't tell the whole story. But all of this is a side-note anyway. What I care about is your actual timings. :) (It also seems like this rename detection is ripe for parallelization, but obviously that's a totally separate topic). > Using the original time limit of 2s for diff.renameLimit, and bumping > merge.renameLimit from 10s to 60s, I found the following timings using > the simple script at the end of this commit message (on an AWS c5.xlarge > which reports as "Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz"): > > N Timing > 1300 1.995s > 7100 59.973s > > So let's round down to nice even numbers and bump the limits from > 400->1000, and from 1000->7000. Sounds good. Thanks for thoroughly measuring and updating. -Peff
