Jeff King <[email protected]> writes:
> On Sat, Oct 07, 2017 at 03:12:08PM -0400, Derrick Stolee wrote:
>
>> In my local copy, I added a test to p4211-line-log.sh that runs "git log
>> --raw -r" and tested it on three copies of the Linux repo. In order, they
>> have 1 packfile (0 loose), 24 packfiles (0 loose), and 23 packfiles
>> (~324,000 loose).
>>
>> 4211.6: git log --raw -r 43.34(42.62+0.65) 40.47(40.16+0.27) -6.6%
>> 4211.6: git log --raw -r 88.77(86.54+2.12) 82.44(81.87+0.52) -7.1%
>> 4211.6: git log --raw -r 108.86(103.97+4.81) 103.92(100.63+3.19) -4.5%
>>
>> We have moderate performance gains for this command, despite the command
>> doing many more things than just checking abbreviations.
>
> Yeah, while it's less exciting than seeing the 90% numbers for a
> micro-benchmark, I think this represents real-world gains (and 5-7% is
> nothing to sneeze at).
Yes! I would even say 5-7% is much better than "nothing to sneeze
at". We do prefer workload closer to the real-world usage over
micro benchmarks, and consider changes that gain by a few percent as
real improvements.
> You might also try adding "--format=%h" or --oneline to your invocation,
> which would compute abbreviations for each commit (making your workload
> more abbrev-heavy and possibly showing off the difference more).
Again, agreed, and I would not consider it would be inflating the
benchmark artificially in favor of the change. "log --oneline" is
not something people use rarely---I'd think it would be quite a
normal thing to do.
> I also think "-r" isn't doing anything. Recursive diffs are the default
> for the "log" porcelain (even for --raw).
That's my fault writing "-r" ;-) Together with your "log --oneline"
suggestion,
git log --oneline --raw
would be a reasonable thing to measure.
Thanks, both.
