On 6/10/2019 8:26 AM, SZEDER Gábor wrote:
On Sat, Jun 08, 2019 at 07:42:42AM -0700, Jeff Hostetler via GitGitGadget wrote:
From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
Teach register_rename_src() to see if new file pair
can simply be appended to the rename_src[] array before
performing the binary search to find the proper insertion
point.
This is a performance optimization. This routine is called
during run_diff_files in status and the caller is iterating
over the sorted index, so we should expect to be able to
append in the normal case. The existing insert logic is
preserved so we don't have to assume that, but simply take
advantage of it if possible.
Could you add a command and performance figures to the commit message
to show off the benefits of this patch?
From the description it's clear that it's a performance optimization,
but it's unclear whether it has a noticeable, or at least measurable
effect, or it's "only" a micro-optimization.
I tried something more substantial than a simple 'git status':
# without this patch
$ time perf record -g ./git log --oneline -m --name-only v2.20.0 >/dev/null
[ ... ]
real 2m4.320s
user 2m0.913s
sys 0m2.284s
$ perf report -g none |grep -E '(diffcore_rename|register_rename_src)'
52.40% 0.79% git git [.] diffcore_rename
0.01% 0.01% git git [.] register_rename_src
but it looks like that while more than half of the considerable
runtime is spent detecting renames, the time spent in
register_rename_src(), the function optimized in this patch, is
negligible.
I just wanted to send an ACK. I'll include perf numbers
and more clarity after I dig up my notes on this.
Jeff
