Re: [PATCH v6 00/11] nd/pack-objects-pack-struct updates
- From
Jeff King <peff@peff.net>
- Date
- Mar 24, 2018, 06:40 UTC
- Message-ID
- <20180324064010.GA30422@sigill.intra.peff.net>
- In-Reply-To
- <4395a668-845e-a66f-2a14-f6a4474c3d4b@ramsayjones.plus.com>
On Fri, Mar 23, 2018 at 04:01:50PM +0000, Ramsay Jones wrote:
Show 5 quoted lines
> 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.
Show 24 quoted lines
> 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