Taylor Blau [off-list ref] writes:
Now that we both can propagate values from the hashcache, and respect
the configuration to enable the hashcache at all, test that both of
these function correctly by hardening their behavior with a test.
When we serve "git fetch" requests from a resulting repository,
because we have namehash available without traversing, we can serve
a packfile to the requestor, using the reachability bitmap to pick
objects that need to be sent, grouping the blobs with the same
namehash to be deltified against each other, resulting in a pack
that is better compressed than before?
What I am wondering is if we can come up with a "now, because we no
longer lose hashcache, we can do X so much better, here are the
numbers".
On Sun, Sep 12, 2021 at 05:46:18PM -0700, Junio C Hamano wrote:
What I am wondering is if we can come up with a "now, because we no
longer lose hashcache, we can do X so much better, here are the
numbers".
Sure, here they are. Bear in mind that these numbers are (a) on git.git
and (b) with `pack.threads` set to 1 so the overall runtime looks more
like CPU time.
Test origin/tb/multi-pack-bitmaps HEAD
-------------------------------------------------------------------------------------
5326.4: simulated clone 1.87(1.80+0.07) 1.46(1.42+0.03) -21.9%
5326.5: simulated fetch 2.66(2.61+0.04) 1.47(1.43+0.04) -44.7%
5326.6: pack to file (bitmap) 2.74(2.62+0.12) 1.89(1.82+0.07) -31.0%
Apologies for taking a little while to respond, I spent longer than I'm
willing to admit double checking these numbers with Peff because of
inconsistencies in my testing setup.
Alas, there they are. They are basically no different than having the
name-hash for single pack bitmaps, it's just now we don't throw them
away when generating a MIDX bitmap from a state where the repository
already has a single-pack bitmap.
Thanks,
Taylor