On Thu, Oct 05, 2017 at 08:39:42AM -0400, Derrick Stolee wrote: > > Actually, I'd just as soon see timings for "git log --format=%h" or "git > > log --raw", as opposed to patches 1 and 2. > > > > You won't see a 90% speedup there, but you will see the actual > > improvement that real-world users are going to experience, which is way > > more important, IMHO. > > > Thanks for thinking hard about this. > > For some real-user context: Some engineers using Git for the Windows repo > were seeing extremely slow commands, such as 'fetch' or 'commit', and when > we took a trace we saw most of the time spinning in this abbreviation code. That's surprising to me. I'd expect fetch to generate up to two abbreviations per fetched ref (for the status table). And for commit to generate only one for the summary. But maybe it was just so painfully slow on your repo that it was noticeable. If there's a case where we're generating a bunch of abbreviated oids, that might be worth looking into. Do you happen to have a stack trace of one of the slow cases showing who is calling into the function? > Our workaround so far has been to set core.abbrev=40. I actually wondered about this. With the new auto-scaling, we'd typically jump straight to 12 or 13 hex-chars on a large repo, and that would be sufficient. So we'd really only need one iteration of the loop. > I'll run some perf numbers for these commands you recommend, and also see if > I can replicate some of the pain points that triggered this change using the > Linux repo. Thanks! -Peff
