From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 00/24] pack-objects: multi-pack verbatim reuse
Date: Fri, 15 Dec 2023 10:37:57 -0500 [thread overview]
Message-ID: <ZXxy1USjjjAbBi++@nand.local> (raw)
In-Reply-To: <20231212081238.GD1117953@coredump.intra.peff.net>
On Tue, Dec 12, 2023 at 03:12:38AM -0500, Jeff King wrote:
> So my question is: how much of what you're seeing is from (1) and (2),
> and how much is from (3)? Because there are other ways to trigger (3),
> such as lowering the window size. For example, if you try your same
> packing example with --window=0, how do the CPU and output size compare
> to the results of your series? (I'd also check peak memory usage).
Interesting question! Here are some preliminary numbers on my machine
(which runs Debian unstable with a Intel Xenon W-2255 CPU @ 3.70GHz and
64GB of RAM).
I ran the following hyperfine command on my testing repository, which
has the Git repository broken up into ~75 packs or so:
$ hyperfine -L v single,multi -L window 0,10 \
--show-output \
-n '{v}-pack reuse, pack.window={window}' \
'git.compile \
-c pack.allowPackReuse={v} \
-c pack.window={window} \
pack-objects --revs --stdout --use-bitmap-index --delta-base-offset <in 2>/dev/null | wc -c'
Which gave the following results for runtime:
Benchmark 1: single-pack reuse, pack.window=0
[...]
Time (mean ± σ): 1.248 s ± 0.004 s [User: 1.160 s, System: 0.188 s]
Range (min … max): 1.244 s … 1.259 s 10 runs
Benchmark 2: multi-pack reuse, pack.window=0
[...]
Time (mean ± σ): 1.075 s ± 0.005 s [User: 0.990 s, System: 0.188 s]
Range (min … max): 1.071 s … 1.088 s 10 runs
Benchmark 3: single-pack reuse, pack.window=10
[...]
Time (mean ± σ): 6.281 s ± 0.024 s [User: 43.727 s, System: 0.492 s]
Range (min … max): 6.252 s … 6.326 s 10 runs
Benchmark 4: multi-pack reuse, pack.window=10
[...]
Time (mean ± σ): 1.028 s ± 0.002 s [User: 1.150 s, System: 0.184 s]
Range (min … max): 1.026 s … 1.032 s 10 runs
Here are the average numbers for the resulting "clone" size in each of
the above configurations:
Benchmark 1: single-pack reuse, pack.window=0
264.443 MB
Benchmark 2: multi-pack reuse, pack.window=0
268.670 MB
Benchmark 3: single-pack reuse, pack.window=10
194.355 MB
Benchmark 4: multi-pack reuse, pack.window=10
266.473 MB
So it looks like setting pack.window=0 (with both single and multi-pack
reuse) yields a similarly sized pack output as multi-pack reuse with any
window setting.
Running the same benchmark as above again, but this time sending the
pack output to /dev/null and instead capturing the maximum RSS value
from `/usr/bin/time -v` gives us the following (averages, in MB):
Benchmark 1: single-pack reuse, pack.window=0
354.224 MB (max RSS)
Benchmark 2: multi-pack reuse, pack.window=0
315.730 MB (max RSS)
Benchmark 3: single-pack reuse, pack.window=10
470.651 MB (max RSS)
Benchmark 4: multi-pack reuse, pack.window=10
328.786 MB (max RSS)
So memory usage is similar between runs except for the single-pack reuse
case with a window size of 10.
It looks like the sweet spot is probably multi-pack reuse with a
small-ish window size, which achieves the best of both worlds (small
pack size, relative to other configurations that reuse large portions of
the pack, and low memory usage).
It's pretty close between multi-pack reuse with a window size of 0 and
a window size of 10. If you want to optimize for pack size, you could
trade a ~4% reduction in pack size for a ~1% increase in peak memory
usage.
Of course, YMMV depending on the repository, packing strategy, and
pack.window configuration (among others) while packing. But this should
give you a general idea of what to expect.
Thanks,
Taylor
next prev parent reply other threads:[~2023-12-15 15:38 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 19:07 [PATCH 00/24] pack-objects: multi-pack verbatim reuse Taylor Blau
2023-11-28 19:07 ` [PATCH 01/24] pack-objects: free packing_data in more places Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:08 ` Taylor Blau
2023-11-28 19:07 ` [PATCH 02/24] pack-bitmap-write: deep-clear the `bb_commit` slab Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:11 ` Taylor Blau
2023-12-12 7:04 ` Jeff King
2023-12-12 16:48 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 03/24] pack-bitmap: plug leak in find_objects() Taylor Blau
2023-12-12 7:04 ` Jeff King
2023-11-28 19:08 ` [PATCH 04/24] midx: factor out `fill_pack_info()` Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:19 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 05/24] midx: implement `DISP` chunk Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:27 ` Taylor Blau
2023-12-03 13:15 ` Junio C Hamano
2023-12-05 19:26 ` Taylor Blau
2023-12-09 1:40 ` Junio C Hamano
2023-12-09 2:30 ` Taylor Blau
2023-12-12 8:03 ` Jeff King
2023-12-13 18:28 ` Taylor Blau
2023-12-13 19:20 ` Junio C Hamano
2023-11-28 19:08 ` [PATCH 06/24] midx: implement `midx_locate_pack()` Taylor Blau
2023-11-28 19:08 ` [PATCH 07/24] midx: implement `--retain-disjoint` mode Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:29 ` Taylor Blau
2023-12-01 8:02 ` Patrick Steinhardt
2023-11-28 19:08 ` [PATCH 08/24] pack-objects: implement `--ignore-disjoint` mode Taylor Blau
2023-11-30 10:18 ` Patrick Steinhardt
2023-11-30 19:32 ` Taylor Blau
2023-12-01 8:17 ` Patrick Steinhardt
2023-12-01 19:58 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 09/24] repack: implement `--extend-disjoint` mode Taylor Blau
2023-12-07 13:13 ` Patrick Steinhardt
2023-12-07 20:28 ` Taylor Blau
2023-12-08 8:19 ` Patrick Steinhardt
2023-12-08 22:48 ` Taylor Blau
2023-12-11 8:18 ` Patrick Steinhardt
2023-12-11 19:59 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 10/24] pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions Taylor Blau
2023-12-07 13:13 ` Patrick Steinhardt
2023-12-07 20:34 ` Taylor Blau
2023-12-08 8:19 ` Patrick Steinhardt
2023-11-28 19:08 ` [PATCH 11/24] pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature Taylor Blau
2023-12-07 13:13 ` Patrick Steinhardt
2023-12-07 14:36 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 12/24] pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()` Taylor Blau
2023-11-28 19:08 ` [PATCH 13/24] pack-objects: parameterize pack-reuse routines over a single pack Taylor Blau
2023-11-28 19:08 ` [PATCH 14/24] pack-objects: keep track of `pack_start` for each reuse pack Taylor Blau
2023-12-07 13:13 ` Patrick Steinhardt
2023-12-07 20:43 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 15/24] pack-objects: pass `bitmapped_pack`'s to pack-reuse functions Taylor Blau
2023-11-28 19:08 ` [PATCH 16/24] pack-objects: prepare `write_reused_pack()` for multi-pack reuse Taylor Blau
2023-12-07 13:13 ` Patrick Steinhardt
2023-12-07 20:47 ` Taylor Blau
2023-11-28 19:08 ` [PATCH 17/24] pack-objects: prepare `write_reused_pack_verbatim()` " Taylor Blau
2023-11-28 19:08 ` [PATCH 18/24] pack-objects: include number of packs reused in output Taylor Blau
2023-11-28 19:08 ` [PATCH 19/24] pack-bitmap: prepare to mark objects from multiple packs for reuse Taylor Blau
2023-11-28 19:08 ` [PATCH 20/24] pack-objects: add tracing for various packfile metrics Taylor Blau
2023-11-28 19:08 ` [PATCH 21/24] t/test-lib-functions.sh: implement `test_trace2_data` helper Taylor Blau
2023-11-28 19:08 ` [PATCH 22/24] pack-objects: allow setting `pack.allowPackReuse` to "single" Taylor Blau
2023-11-28 19:08 ` [PATCH 23/24] pack-bitmap: reuse objects from all disjoint packs Taylor Blau
2023-11-28 19:08 ` [PATCH 24/24] t/perf: add performance tests for multi-pack reuse Taylor Blau
2023-11-30 10:18 ` [PATCH 00/24] pack-objects: multi-pack verbatim reuse Patrick Steinhardt
2023-11-30 19:39 ` Taylor Blau
2023-12-01 8:31 ` Patrick Steinhardt
2023-12-01 20:02 ` Taylor Blau
2023-12-04 8:49 ` Patrick Steinhardt
2023-12-12 8:12 ` Jeff King
2023-12-15 15:37 ` Taylor Blau [this message]
2023-12-21 11:13 ` Jeff King
2024-01-04 22:22 ` Taylor Blau
2023-12-14 22:23 ` [PATCH v2 00/26] " Taylor Blau
2023-12-14 22:23 ` [PATCH v2 01/26] pack-objects: free packing_data in more places Taylor Blau
2023-12-14 22:23 ` [PATCH v2 02/26] pack-bitmap-write: deep-clear the `bb_commit` slab Taylor Blau
2023-12-14 22:23 ` [PATCH v2 03/26] pack-bitmap: plug leak in find_objects() Taylor Blau
2023-12-14 22:23 ` [PATCH v2 04/26] midx: factor out `fill_pack_info()` Taylor Blau
2023-12-14 22:23 ` [PATCH v2 05/26] midx: implement `BTMP` chunk Taylor Blau
2023-12-14 22:23 ` [PATCH v2 06/26] midx: implement `midx_locate_pack()` Taylor Blau
2023-12-14 22:23 ` [PATCH v2 07/26] pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions Taylor Blau
2023-12-14 22:23 ` [PATCH v2 08/26] ewah: implement `bitmap_is_empty()` Taylor Blau
2023-12-14 22:24 ` [PATCH v2 09/26] pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature Taylor Blau
2023-12-14 22:24 ` [PATCH v2 10/26] pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()` Taylor Blau
2023-12-14 22:24 ` [PATCH v2 11/26] pack-objects: parameterize pack-reuse routines over a single pack Taylor Blau
2023-12-14 22:24 ` [PATCH v2 12/26] pack-objects: keep track of `pack_start` for each reuse pack Taylor Blau
2023-12-14 22:24 ` [PATCH v2 13/26] pack-objects: pass `bitmapped_pack`'s to pack-reuse functions Taylor Blau
2023-12-14 22:24 ` [PATCH v2 14/26] pack-objects: prepare `write_reused_pack()` for multi-pack reuse Taylor Blau
2023-12-14 22:24 ` [PATCH v2 15/26] pack-objects: prepare `write_reused_pack_verbatim()` " Taylor Blau
2023-12-14 22:24 ` [PATCH v2 16/26] pack-objects: include number of packs reused in output Taylor Blau
2023-12-14 22:24 ` [PATCH v2 17/26] git-compat-util.h: implement checked size_t to uint32_t conversion Taylor Blau
2023-12-14 22:24 ` [PATCH v2 18/26] midx: implement `midx_preferred_pack()` Taylor Blau
2023-12-14 22:24 ` [PATCH v2 19/26] pack-revindex: factor out `midx_key_to_pack_pos()` helper Taylor Blau
2023-12-14 22:24 ` [PATCH v2 20/26] pack-revindex: implement `midx_pair_to_pack_pos()` Taylor Blau
2023-12-14 22:24 ` [PATCH v2 21/26] pack-bitmap: prepare to mark objects from multiple packs for reuse Taylor Blau
2023-12-14 22:24 ` [PATCH v2 22/26] pack-objects: add tracing for various packfile metrics Taylor Blau
2023-12-14 22:24 ` [PATCH v2 23/26] t/test-lib-functions.sh: implement `test_trace2_data` helper Taylor Blau
2023-12-14 22:24 ` [PATCH v2 24/26] pack-objects: allow setting `pack.allowPackReuse` to "single" Taylor Blau
2023-12-14 22:24 ` [PATCH v2 25/26] pack-bitmap: enable reuse from all bitmapped packs Taylor Blau
2023-12-14 22:24 ` [PATCH v2 26/26] t/perf: add performance tests for multi-pack reuse Taylor Blau
2023-12-15 0:06 ` [PATCH v2 00/26] pack-objects: multi-pack verbatim reuse Junio C Hamano
2023-12-15 0:38 ` Taylor Blau
2023-12-15 0:40 ` Junio C Hamano
2023-12-15 1:25 ` Taylor Blau
2023-12-21 10:51 ` Jeff King
2024-01-04 22:24 ` Taylor Blau
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=ZXxy1USjjjAbBi++@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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).