From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 4/5] pack-bitmap.c: avoid repeated `pack_pos_to_offset()` during reuse
Date: Wed, 04 Sep 2024 11:54:18 -0700 [thread overview]
Message-ID: <xmqq1q1z9rmt.fsf@gitster.g> (raw)
In-Reply-To: <afa25c8806b0e80f1d3ed46f29eb164cab4583ac.1724793201.git.me@ttaylorr.com> (Taylor Blau's message of "Tue, 27 Aug 2024 17:13:36 -0400")
Taylor Blau <me@ttaylorr.com> writes:
> @@ -2055,17 +2055,18 @@ static int try_partial_reuse(struct bitmap_index *bitmap_git,
> struct bitmapped_pack *pack,
> size_t bitmap_pos,
> uint32_t pack_pos,
> + off_t offset,
> struct bitmap *reuse,
> struct pack_window **w_curs)
> {
> - off_t offset, delta_obj_offset;
> + off_t delta_obj_offset;
> enum object_type type;
> unsigned long size;
>
> if (pack_pos >= pack->p->num_objects)
> return -1; /* not actually in the pack */
>
> - offset = delta_obj_offset = pack_pos_to_offset(pack->p, pack_pos);
We are now passing redundant piece of information "offset" that
could be derived from two other parameters, which feels a bit icky,
I suspect that try_partial_reuse() can be taught not to require
pack_pos and instead work entirely on offset
- The caller can pass a very large offset to represent "not
actually in the pack" early return condition.
- The logic to punt on a delta pointing backwards can be done by
comparing the base_offset and offset, instead of comparing the
base_pos and pack_pos.
but it may not be worth the effort, unless we are going to do
similar clean-up globally in all the codepaths that access
packfiles.
Thanks.
next prev parent reply other threads:[~2024-09-04 18:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 21:13 [PATCH 0/5] pack-objects: brown-paper-bag fixes for multi-pack reuse Taylor Blau
2024-08-27 21:13 ` [PATCH 1/5] t/t5332-multi-pack-reuse.sh: verify pack generation with --strict Taylor Blau
2024-08-27 21:13 ` [PATCH 2/5] pack-bitmap: tag bitmapped packs with their corresponding MIDX Taylor Blau
2024-08-28 0:14 ` Junio C Hamano
2024-08-29 18:58 ` Taylor Blau
2024-09-05 9:00 ` Jeff King
2024-09-17 9:58 ` Taylor Blau
2024-08-27 21:13 ` [PATCH 3/5] builtin/pack-objects.c: translate bit positions during pack-reuse Taylor Blau
2024-09-04 18:18 ` Junio C Hamano
2024-08-27 21:13 ` [PATCH 4/5] pack-bitmap.c: avoid repeated `pack_pos_to_offset()` during reuse Taylor Blau
2024-09-04 18:54 ` Junio C Hamano [this message]
2024-09-04 19:28 ` Taylor Blau
2024-08-27 21:13 ` [PATCH 5/5] builtin/pack-objects.c: do not open-code `MAX_PACK_OBJECT_HEADER` Taylor Blau
2024-09-04 18:56 ` [PATCH 0/5] pack-objects: brown-paper-bag fixes for multi-pack reuse Junio C Hamano
2024-09-04 19:28 ` Taylor Blau
2024-09-05 9:10 ` Jeff King
2024-09-05 15:21 ` Junio C Hamano
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=xmqq1q1z9rmt.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.