From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
Jeff King <peff@peff.net>, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH 00/11] pack-bitmap: convert offset to ref deltas where possible
Date: Thu, 10 Oct 2024 09:46:00 -0700 [thread overview]
Message-ID: <xmqqzfnblxdj.fsf@gitster.g> (raw)
In-Reply-To: <cover.1728505840.git.me@ttaylorr.com> (Taylor Blau's message of "Wed, 9 Oct 2024 16:30:52 -0400")
Taylor Blau <me@ttaylorr.com> writes:
> This patch series enables more objects to be candidates for verbatim
> reuse when generating a pack with the aide of reachability bitmaps.
>
> By the end of this series, two new classes of objects are now reuse
> candidates which were not before. They are:
>
> - Cross-pack deltas. In multi-pack bitmaps, if the delta and base
> were selected from different packs, the delta was not reusable.
Hmph. Suppose that you need to send object X, you happen to have X
as a ofs-delta against Y, but Y may appear in multiple packs.
Even if the copy of Y you are going to send together with X is from
the same packfile, you may not be sending all the objects between X
and Y in the original local packfile, so you would need to recompute
the offset to give ofs-delta X to the distance between X and Y in
the resulting packstream, no?
So when you pick the copy of Y out of another pack, what's so
different? After emitting Y to the resulting pack stream (and
remembering where in the packstream you did so), when it is X's turn
to be emitted, shouldn't you be able to compute the distance in the
resulting packstream to represent X as an ofs-delta against Y, which
should already be happening when you had both X and Y in the same
original pack?
> - Thin deltas. In both single- and multi-pack bitmaps, we did not
> consider reusing deltas whose base object appears in the 'haves'
> bitmap.
I hope this optimization does not kick in unless the receiving end
is prepared to do "index-pack --fix-thin".
I've never thought about this specifically, but it is interesting to
realize that by definition "thin" deltas cannot be ofs-deltas.
> Of course, REF_DELTAs have a less compact representation than
> OFS_DELTAs, so the resulting packs will trade off some CPU time for a
> slightly larger pack.
Is comparing ref- vs ofs- delta a meaningful thing to do in the
context of this series?
What does the current code without these patches do in the same
situation? Give up on reusing the existing delta and then? If we
send the base representation instead, the comparison is "we
currently do not use delta, but with this change we can reuse delta
(even though we do not bother recompute the offset and instead use
ref-delta)".
Do we recompute the delta on the fly and show it as an ofs-delta
with the current code? Then the comparison would be "we spend time
doing diff-delta once right now but instead reuse an existing one
(even though we do not bother recompute the offset and instead use
ref-delta)".
next prev parent reply other threads:[~2024-10-10 16:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 20:30 [PATCH 00/11] pack-bitmap: convert offset to ref deltas where possible Taylor Blau
2024-10-09 20:31 ` [PATCH 01/11] pack-bitmap.c: do not pass `pack_pos` to `try_partial_reuse()` Taylor Blau
2024-10-09 20:31 ` [PATCH 02/11] pack-bitmap.c: avoid unnecessary `offset_to_pack_pos()` Taylor Blau
2024-10-09 20:31 ` [PATCH 03/11] pack-bitmap.c: delay calling 'offset_to_pack_pos()' Taylor Blau
2024-10-09 20:31 ` [PATCH 04/11] pack-bitmap.c: compare `base_offset` to `delta_obj_offset` Taylor Blau
2024-10-09 20:31 ` [PATCH 05/11] pack-bitmap.c: extract `find_base_bitmap_pos()` Taylor Blau
2024-10-09 20:31 ` [PATCH 06/11] pack-bitmap: drop `from_midx` field from `bitmapped_pack` Taylor Blau
2024-10-09 20:31 ` [PATCH 07/11] write_reused_pack_one(): translate bit positions directly Taylor Blau
2024-10-11 8:16 ` Jeff King
2024-11-04 20:36 ` Taylor Blau
2024-10-09 20:31 ` [PATCH 08/11] t5332: enable OFS_DELTAs via test_pack_objects_reused Taylor Blau
2024-10-11 8:19 ` Jeff King
2024-11-04 20:50 ` Taylor Blau
2024-10-09 20:31 ` [PATCH 09/11] pack-bitmap: enable cross-pack delta reuse Taylor Blau
2024-10-11 8:31 ` Jeff King
2024-11-04 21:00 ` Taylor Blau
2024-10-09 20:31 ` [PATCH 10/11] pack-bitmap.c: record whether the result was filtered Taylor Blau
2024-10-11 8:35 ` Jeff King
2024-11-04 21:01 ` Taylor Blau
2024-10-09 20:31 ` [PATCH 11/11] pack-bitmap: enable reusing deltas with base objects in 'haves' bitmap Taylor Blau
2024-10-10 16:46 ` Junio C Hamano [this message]
2024-10-10 17:07 ` [PATCH 00/11] pack-bitmap: convert offset to ref deltas where possible Taylor Blau
2024-10-10 20:20 ` Junio C Hamano
2024-10-10 20:32 ` Taylor Blau
2024-10-11 7:54 ` Jeff King
2024-10-11 8:01 ` Jeff King
2024-10-11 16:23 ` Junio C Hamano
2024-10-11 8:38 ` Jeff King
2024-11-19 23:08 ` Taylor Blau
2024-11-19 23:34 ` Taylor Blau
2024-12-18 12:57 ` Jeff King
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=xmqqzfnblxdj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=newren@gmail.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).