git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH v4 21/23] t/perf: add tests for pack bitmaps
Date: Sat, 21 Dec 2013 09:00:42 -0500	[thread overview]
Message-ID: <20131221140042.GU21145@sigill.intra.peff.net> (raw)
In-Reply-To: <20131221135651.GA20818@sigill.intra.peff.net>

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>
---
 t/perf/p5310-pack-bitmaps.sh | 56 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100755 t/perf/p5310-pack-bitmaps.sh

diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh
new file mode 100755
index 0000000..8c6ae45
--- /dev/null
+++ b/t/perf/p5310-pack-bitmaps.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+test_description='Tests pack performance using bitmaps'
+. ./perf-lib.sh
+
+test_perf_large_repo
+
+# note that we do everything through config,
+# since we want to be able to compare bitmap-aware
+# git versus non-bitmap git
+test_expect_success 'setup bitmap config' '
+	git config pack.writebitmaps true
+'
+
+test_perf 'repack to disk' '
+	git repack -ad
+'
+
+test_perf 'simulated clone' '
+	git pack-objects --stdout --all </dev/null >/dev/null
+'
+
+test_perf 'simulated fetch' '
+	have=$(git rev-list HEAD~100 -1) &&
+	{
+		echo HEAD &&
+		echo ^$have
+	} | git pack-objects --revs --stdout >/dev/null
+'
+
+test_expect_success 'create partial bitmap state' '
+	# pick a commit to represent the repo tip in the past
+	cutoff=$(git rev-list HEAD~100 -1) &&
+	orig_tip=$(git rev-parse HEAD) &&
+
+	# now kill off all of the refs and pretend we had
+	# just the one tip
+	rm -rf .git/logs .git/refs/* .git/packed-refs
+	git update-ref HEAD $cutoff
+
+	# and then repack, which will leave us with a nice
+	# big bitmap pack of the "old" history, and all of
+	# the new history will be loose, as if it had been pushed
+	# up incrementally and exploded via unpack-objects
+	git repack -Ad
+
+	# and now restore our original tip, as if the pushes
+	# had happened
+	git update-ref HEAD $orig_tip
+'
+
+test_perf 'partial bitmap' '
+	git pack-objects --stdout --all </dev/null >/dev/null
+'
+
+test_done
-- 
1.8.5.1.399.g900e7cd

  parent reply	other threads:[~2013-12-21 14:00 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-21 13:56 [PATCH v4 0/22] pack bitmaps Jeff King
2013-12-21 13:59 ` [PATCH v4 01/23] sha1write: make buffer const-correct Jeff King
2013-12-22  9:06   ` Christian Couder
2013-12-21 13:59 ` [PATCH v4 02/23] revindex: Export new APIs Jeff King
2013-12-21 13:59 ` [PATCH v4 03/23] pack-objects: Refactor the packing list Jeff King
2013-12-21 13:59 ` [PATCH v4 04/23] pack-objects: factor out name_hash Jeff King
2013-12-21 13:59 ` [PATCH v4 05/23] revision: allow setting custom limiter function Jeff King
2013-12-21 13:59 ` [PATCH v4 06/23] sha1_file: export `git_open_noatime` Jeff King
2013-12-21 13:59 ` [PATCH v4 07/23] compat: add endianness helpers Jeff King
2013-12-21 13:59 ` [PATCH v4 08/23] ewah: compressed bitmap implementation Jeff King
2014-01-23  2:05   ` Jonathan Nieder
2014-01-23 18:33     ` Jeff King
2014-01-23 18:35       ` [PATCH 1/2] compat: move unaligned helpers to bswap.h Jeff King
2014-01-23 19:41         ` Jonathan Nieder
2014-01-23 19:44           ` Jeff King
2014-01-23 19:56             ` Jonathan Nieder
2014-01-23 20:04               ` Jeff King
2014-01-23 20:08                 ` Jonathan Nieder
2014-01-23 20:09                   ` Jeff King
2014-01-23 18:35       ` [PATCH 2/2] ewah: support platforms that require aligned reads Jeff King
2014-01-23 19:52       ` [PATCH v4 08/23] ewah: compressed bitmap implementation Jonathan Nieder
2014-01-23 20:03         ` Jeff King
2014-01-23 20:12           ` Jonathan Nieder
2014-01-23 20:13             ` Jeff King
2014-01-23 20:23           ` Jonathan Nieder
2014-01-23 20:29             ` Jeff King
2014-01-23 20:38           ` Jeff King
2014-01-23 20:14       ` Shawn Pearce
2014-01-23 20:26         ` Jeff King
2014-01-23 21:53           ` brian m. carlson
2014-01-23 22:07             ` Jeff King
2014-01-23 22:17               ` Jonathan Nieder
2014-01-23 22:26                 ` Jeff King
2014-01-23 22:33                   ` Jonathan Nieder
2014-01-23 20:18       ` Jonathan Nieder
2014-01-23 21:20       ` [PATCH v2 0/3] unaligned reads from .bitmap files Jeff King
2014-01-23 21:23         ` [PATCH 1/3] block-sha1: factor out get_be and put_be wrappers Jeff King
2014-01-23 23:19           ` Jonathan Nieder
2014-01-23 21:26         ` [PATCH 2/3] read-cache: use get_be32 instead of hand-rolled ntoh_l Jeff King
2014-01-23 23:34           ` Jonathan Nieder
2014-01-24  2:22             ` Jeff King
2014-01-23 21:27         ` [PATCH 3/3] ewah: support platforms that require aligned reads Jeff King
2014-01-23 23:44           ` Jonathan Nieder
2014-01-23 23:49             ` Vicent Martí
2014-01-24  0:15               ` Jonathan Nieder
2014-01-23 23:17         ` [PATCH v2 0/3] unaligned reads from .bitmap files Jonathan Nieder
2013-12-21 13:59 ` [PATCH v4 09/23] documentation: add documentation for the bitmap format Jeff King
2013-12-21 14:00 ` [PATCH v4 10/23] pack-bitmap: add support for bitmap indexes Jeff King
2013-12-21 14:00 ` [PATCH v4 11/23] pack-objects: split add_object_entry Jeff King
2013-12-21 14:00 ` [PATCH v4 12/23] pack-objects: use bitmaps when packing objects Jeff King
2013-12-21 14:00 ` [PATCH v4 13/23] rev-list: add bitmap mode to speed up object lists Jeff King
2013-12-21 14:00 ` [PATCH v4 14/23] pack-objects: implement bitmap writing Jeff King
2013-12-21 14:00 ` [PATCH v4 15/23] repack: stop using magic number for ARRAY_SIZE(exts) Jeff King
2013-12-21 14:00 ` [PATCH v4 16/23] repack: turn exts array into array-of-struct Jeff King
2013-12-21 14:00 ` [PATCH v4 17/23] repack: handle optional files created by pack-objects Jeff King
2013-12-21 14:00 ` [PATCH v4 18/23] repack: consider bitmaps when performing repacks Jeff King
2013-12-21 14:00 ` [PATCH v4 19/23] count-objects: recognize .bitmap in garbage-checking Jeff King
2013-12-21 14:00 ` [PATCH v4 20/23] t: add basic bitmap functionality tests Jeff King
2013-12-21 14:00 ` Jeff King [this message]
2013-12-21 14:00 ` [PATCH v4 22/23] pack-bitmap: implement optional name_hash cache Jeff King
2013-12-21 14:00 ` [PATCH v4 23/23] compat/mingw.h: Fix the MinGW and msvc builds Jeff King
2013-12-25 22:08   ` Erik Faye-Lund
2013-12-28 10:00     ` Jeff King
2013-12-28 10:06       ` Vicent Martí
2013-12-28 15:58       ` Ramsay Jones
2013-12-21 14:03 ` [PATCH v4 0/22] pack bitmaps Jeff King
2013-12-21 14:05 ` Jeff King
2013-12-21 18:34 ` Thomas Rast

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131221140042.GU21145@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).