On Fri, Mar 23, 2018 at 04:01:50PM +0000, Ramsay Jones wrote:

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?

Yes to both.

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

Yes, though it was all being run out of disk cache anyway. I also have a
lot of RAM. :)

The ffmpeg repository only has ~550k objects. So that's log(19), and
we'd expect radix to be something like 8-9x faster than a comparison
sort. But at some point the constants take over too (each O(n) round the
radix sort actually has to look at the items twice, and of course there
are negative cache effects when duplicating the array).

So your numbers match what I'd expect.

Thanks for looking into this, even if it was a wild
goose chase. :)

No problem. I think it's nice to sanity check my own hand-waving once in
a while. ;)

-Peff