Jeff King <peff@xxxxxxxx> 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.
