Re: [PATCH v2 7/7] t5326: test propagating hashcache values
From: Jeff King <hidden>
Date: 2021-09-16 22:49:53
On Tue, Sep 14, 2021 at 06:06:16PM -0400, Taylor Blau wrote:
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.
Like the hash-cache in classic single-pack bitmaps, this helps more
proportionally the more up-to-date your bitmap coverage is. When our
bitmap coverage is out-of-date with the ref tips, we spend more time
proportionally traversing, and all of that traversal gets the name-hash
filled in.
But for the up-to-date bitmaps, this helps quite a bit. These numbers
are on git.git, with `pack.threads=1` to help see the difference
reflected in the overall runtime.
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%The percentages here match timings I did. Doing it with linux.git gives bigger absolute numbers, but I think this is sufficient (and a lot less painful when people are trying to replicate).
quoted hunk ↗ jump to hunk
+test_expect_success 'hash-cache values are propagated from pack bitmaps' ' + rm -fr repo && + git init repo && + test_when_finished "rm -fr repo" && + ( + cd repo && + + git config pack.writeBitmapHashCache true &&
This is the default as of your earlier commits, so we could probably drop this. I don't mind keeping it as explicit documentation of what we expect, though. -Peff