Re: [PATCH v2 4/4] Bump rename limit defaults (yet again)
- From
Jeff King <peff@peff.net>
- Date
- Jul 14, 2021, 16:43 UTC
- Message-ID
- <YO8UPtFr4wRhVTXE@coredump.intra.peff.net>
- In-Reply-To
- <8f1deb6dd16a0c0d88cf594d2019b3096dbe5383.1626225154.git.gitgitgadget@gmail.com>
On Wed, Jul 14, 2021 at 01:12:33AM +0000, Elijah Newren via GitGitGadget wrote:
Show 5 quoted lines
> 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).
Show 11 quoted lines
> 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