summaryrefslogtreecommitdiff
path: root/pack-bitmap.h
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2013-12-21 09:00:42 -0500
committerJunio C Hamano <gitster@pobox.com>2013-12-30 12:19:23 -0800
commitbbcefa1f3f8355921137dd7a097b3ee3db66f023 (patch)
tree99c6e9e4bc6b5de153e0433d4d8839baf55de615 /pack-bitmap.h
parent212f2ffbf0331ceca1a4bc1820ab1ac5c5115e8b (diff)
downloadgit-bbcefa1f3f8355921137dd7a097b3ee3db66f023.tar.gz
t/perf: add tests for pack bitmaps
This adds a few basic perf tests for the pack bitmap code to show off its improvements. The tests are: 1. How long does it take to do a repack (it gets slower with bitmaps, since we have to do extra work)? 2. How long does it take to do a clone (it gets faster with bitmaps)? 3. How does a small fetch perform when we've just repacked? 4. How does a clone perform when we haven't repacked since a week of pushes? Here are results against linux.git: Test origin/master this tree ----------------------------------------------------------------------- 5310.2: repack to disk 33.64(32.64+2.04) 67.67(66.75+1.84) +101.2% 5310.3: simulated clone 30.49(29.47+2.05) 1.20(1.10+0.10) -96.1% 5310.4: simulated fetch 3.49(6.79+0.06) 5.57(22.35+0.07) +59.6% 5310.6: partial bitmap 36.70(43.87+1.81) 8.18(21.92+0.73) -77.7% You can see that we do take longer to repack, but we do way better for further clones. A small fetch performs a bit worse, as we spend way more time on delta compression (note the heavy user CPU time, as we have 8 threads) due to the lack of name hashes for the bitmapped objects. The final test shows how the bitmaps degrade over time between packs. There's still a significant speedup over the non-bitmap case, but we don't do quite as well (we have to spend time accessing the "new" objects the old fashioned way, including delta compression). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pack-bitmap.h')
0 files changed, 0 insertions, 0 deletions