Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

Jeff King [off-list ref] writes:

On Sat, Oct 07, 2017 at 03:12:08PM -0400, Derrick Stolee wrote:

quoted

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.