On 23/03/18 05:50, Jeff King wrote: > On Thu, Mar 22, 2018 at 10:46:09PM -0400, Jeff King wrote: [snip] > I was curious whether my hand-waving there was true. It turns out that > it is: the radix sort has stayed about the same speed but the comparison > sort has gotten even slower. Here are best-of-five timings for "git > cat-file --batch-check='%(objectsize:disk)'", which does very little > besides generate the rev-index: Not that it matters, but I assume this was something like: $ time (echo HEAD | git cat-file --batch-check="%(objectsize:disk)") ... and I suspect it was on the linux.git repo, yes? I used to have a copy of the linux repo on disk, but I had to delete it a while ago to recover some disk space (no matter how big disks get, they never seem big enough)! If I do this on my biggest repo (ffmpeg), I get: $ cd ../ffmpeg/ $ time (echo HEAD | git cat-file --batch-check="%(objectsize:disk)") 227 real 0m0.037s user 0m0.020s sys 0m0.004s $ time (echo HEAD | ../git/git-cat-file --batch-check="%(objectsize:disk)") 227 real 0m0.146s user 0m0.112s sys 0m0.012s $ Where I'm using a version with my patch applied, rather than reverting commit 8b8dfd5132. A 395% slowdown is bad enough, but not as bad as a factor of 11! I bet you have a much more modern system (with a fast SSD) than my old laptop. :-D > [current master, using radix sort] > real 0m0.104s > user 0m0.088s > sys 0m0.016s > > [reverting 8b8dfd5132, going back to qsort] > real 0m1.193s > user 0m1.176s > sys 0m0.016s > > So it's now a factor of 11. Yikes. Thanks for looking into this, even if it was a wild goose chase. :) ATB, Ramsay Jones
