Message ID | fdf71432b32ef47b23b79ddfc3db8de8734ef7a5.1631657157.git.me@ttaylorr.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | pack-bitmap: permute existing namehash values | expand |
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). > +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
diff --git a/t/t5326-multi-pack-bitmaps.sh b/t/t5326-multi-pack-bitmaps.sh index 4ad7c2c969..24148ca35b 100755 --- a/t/t5326-multi-pack-bitmaps.sh +++ b/t/t5326-multi-pack-bitmaps.sh @@ -283,4 +283,36 @@ test_expect_success 'pack.preferBitmapTips' ' ) ' +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 && + + test_commit base && + test_commit base2 && + git repack -adb && + + test-tool bitmap dump-hashes >pack.raw && + test_file_not_empty pack.raw && + sort pack.raw >pack.hashes && + + test_commit new && + git repack && + git multi-pack-index write --bitmap && + + test-tool bitmap dump-hashes >midx.raw && + sort midx.raw >midx.hashes && + + # ensure that every namehash in the pack bitmap can be found in + # the midx bitmap (i.e., that there are no oid-namehash pairs + # unique to the pack bitmap). + comm -23 pack.hashes midx.hashes >dropped.hashes && + test_must_be_empty dropped.hashes + ) +' + test_done
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% Signed-off-by: Taylor Blau <me@ttaylorr.com> --- t/t5326-multi-pack-bitmaps.sh | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)