All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	 Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] packfile: fix perf regression with many packs
Date: Thu, 13 Aug 2026 06:52:30 -0700	[thread overview]
Message-ID: <xmqq33wiunz5.fsf@gitster.g> (raw)
In-Reply-To: <an1zz02GNqDu-0Oz@pks.im> (Patrick Steinhardt's message of "Thu, 13 Aug 2026 09:35:49 +0200")

Patrick Steinhardt <ps@pks.im> writes:

>> -void packfile_list_append(struct packfile_list *list, struct packed_git *pack)
>> +void packfile_list_append(struct packfile_list *list, struct packed_git *pack,
>> +			  int is_new)
>>  {
>>  	struct packfile_list_entry *entry;
>>  
>> -	entry = packfile_list_remove_internal(list, pack);
>> +	entry = is_new ? NULL : packfile_list_remove_internal(list, pack);
>>  	if (!entry) {
>>  		entry = xmalloc(sizeof(*entry));
>>  		entry->pack = pack;
>
> I wonder whether we should slightly reformulate this and rename `is_new`
> to `accept_duplicates`. Because ultimately, that is what we're doing
> now: instead of ensuring that the packfile is unique in the list, we
> just don't care and just append the entry to the list.

I had the same thought.  The current callers might have been vetted
thoroughly, but the next caller might not be so careful, and for
that matter, the code paths to reach current caller may change in
the future to break the promise of ever throwing a new pack at
packfile_list.

Is it well understood what bad things it will lead to to have
duplicated entries on a packfile_list (other than it would make it
even less efficient to prove the non-existence of a pack on it, and
possibly a bit more efficient, depending on where duplicates are, to
prove the existence of a pack on it?)


  parent reply	other threads:[~2026-08-13 13:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 19:11 [PATCH] packfile: fix perf regression with many packs Johannes Schindelin via GitGitGadget
2026-08-12 19:51 ` Junio C Hamano
2026-08-12 21:29   ` Jeff King
2026-08-13  7:35     ` Patrick Steinhardt
2026-08-13  8:25     ` Johannes Schindelin
2026-08-13 16:10       ` Jeff King
2026-08-13  8:26   ` Johannes Schindelin
2026-08-12 22:29 ` Ben Knoble
2026-08-13  9:04   ` Johannes Schindelin
2026-08-13 11:18     ` Ben Knoble
2026-08-13  7:35 ` Patrick Steinhardt
2026-08-13  9:20   ` Johannes Schindelin
2026-08-13 10:01     ` Patrick Steinhardt
2026-08-13 10:42       ` [PATCH] packfile: fix perf regression with many packsy Johannes Schindelin
2026-08-13 11:12         ` Patrick Steinhardt
2026-08-13 13:52   ` Junio C Hamano [this message]
2026-08-13 16:15   ` [PATCH] packfile: fix perf regression with many packs Jeff King
2026-08-13 14:56 ` [PATCH v2] " Johannes Schindelin via GitGitGadget

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=xmqq33wiunz5.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --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 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.