On Mon, Nov 12, 2018 at 11:21:51AM -0500, Jeff King wrote: > No, but they don't even really need to be actual objects. So I suspect > something like: > > git init > for i in $(seq 256); do > i=$(printf %02x $i) > mkdir -p .git/objects/$i > for j in $(seq --format=%038g 1000); do > echo foo >.git/objects/$i/$j > done > done > git index-pack -v --stdin </path/to/git.git/objects/pack/XYZ.pack > > might work (for various values of 1000). The shell loop would probably > be faster as perl, too. :) > > Make sure you clear the object directory between runs, though (otherwise > the subsequent index-pack's really do find collisions and spend time > accessing the objects). Below are my results. They are not as comprehensive as Ævar's tests. Similary I kept the loose objects between tests and removed the packs instead. And I also used the "echo 3 | sudo tee /proc/sys/vm/drop_caches" trick :) This is with git.git: origin/master jk/loose-object-cache 256*100 objects 520s 13.5s (-97%) 256*1000 objects 826s 59s (-93%) I've started a 256*10K setup but that's still creating the 2.5M loose objects. I'll post the results when it's done. I would expect that jk/loose-object-cache is still marginally faster than origin/master based on a simple linear extrapolation.