All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org,  Jeff King <peff@peff.net>,
	 Elijah Newren <newren@gmail.com>,
	 Patrick Steinhardt <ps@pks.im>
Subject: Re: [RFC PATCH 02/14] strvec: introduce `strvec_init_alloc()`
Date: Thu, 26 Feb 2026 12:58:48 -0800	[thread overview]
Message-ID: <xmqq4in3xlvb.fsf@gitster.g> (raw)
In-Reply-To: <xmqqh5r31byc.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 26 Feb 2026 12:34:03 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Taylor Blau <me@ttaylorr.com> writes:
>
>> When the caller knows upfront how many elements will be pushed onto a
>> `strvec`, it is useful to pre-allocate enough space in the array to fit
>> that many elements (and one additional slot to store NULL, indicating
>> the end of the list.)
>>
>> Introduce `strvec_init_alloc()`, which allocates the backing array large
>> enough to hold `alloc` elements and the termination marker without
>> further reallocation.
>>
>> Signed-off-by: Taylor Blau <me@ttaylorr.com>
>> ---
>>  strvec.c | 7 +++++++
>>  strvec.h | 5 +++++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/strvec.c b/strvec.c
>> index f8de79f5579..f7f32a53b56 100644
>> --- a/strvec.c
>> +++ b/strvec.c
>> @@ -10,6 +10,13 @@ void strvec_init(struct strvec *array)
>>  	memcpy(array, &blank, sizeof(*array));
>>  }
>>  
>> +void strvec_init_alloc(struct strvec *array, size_t alloc)
>> +{
>> +	CALLOC_ARRAY(array->v, st_add(alloc, 1));
>> +	array->nr = 0;
>> +	array->alloc = alloc + 1;
>> +}
>
> It is not satisifying that strvec_init() does *not* become a thin
> wrapper around this that says "my initial allocation is for zero
> elements", but that cannot be done easily as a strvec that begins as
> an empty one has a small optimization to avoid one-slot allocation
> only to store NULL.  So, ... OK.

Actually, we should do the same optimization if a caller explicitly
asks

	strvec_init_alloc(&array, 0);

So perhaps we could do this if we wanted to encapsulate the tricky
bits in a single place for maintainability.

 strvec.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git c/strvec.c w/strvec.c
index f8de79f557..cbe72e9411 100644
--- c/strvec.c
+++ w/strvec.c
@@ -4,10 +4,21 @@
 
 const char *empty_strvec[] = { NULL };
 
+void strvec_init_alloc(struct strvec *array, size_t alloc)
+{
+	if (!alloc) {
+		struct strvec blank = STRVEC_INIT;
+		memcpy(array, &blank, sizeof(*array));
+	} else {
+		CALLOC_ARRAY(array->v, st_add(alloc, 1));
+		array->nr = 0;
+		array->alloc = alloc + 1;
+	}
+}
+
 void strvec_init(struct strvec *array)
 {
-	struct strvec blank = STRVEC_INIT;
-	memcpy(array, &blank, sizeof(*array));
+	strvec_init(array, 0);
 }
 
 void strvec_push_nodup(struct strvec *array, char *value)

  reply	other threads:[~2026-02-26 20:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25  0:20 [RFC PATCH 00/14] repack: incremental MIDX/bitmap-based repacking Taylor Blau
2026-02-25  0:20 ` [RFC PATCH 06/14] repack: track the ODB source via existing_packs Taylor Blau
2026-02-25  0:21   ` Taylor Blau
2026-02-25  0:23   ` Taylor Blau
2026-02-25  0:20 ` [RFC PATCH 01/14] midx: use `string_list` for retained MIDX files Taylor Blau
2026-02-26 20:29   ` Junio C Hamano
2026-02-27  3:02     ` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 02/14] strvec: introduce `strvec_init_alloc()` Taylor Blau
2026-02-26 20:34   ` Junio C Hamano
2026-02-26 20:58     ` Junio C Hamano [this message]
2026-02-27  3:07       ` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 03/14] midx: use `strvec` for `keep_hashes` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 04/14] midx: introduce `--checksum-only` for incremental MIDX writes Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 05/14] midx: support custom `--base` " Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 07/14] midx: expose `midx_layer_contains_pack()` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 08/14] repack-midx: factor out `repack_prepare_midx_command()` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 09/14] repack-midx: extract `repack_fill_midx_stdin_packs()` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 10/14] repack-geometry: prepare for incremental MIDX repacking Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 11/14] builtin/repack.c: convert `--write-midx` to an `OPT_CALLBACK` Taylor Blau
2026-02-25  0:21 ` [RFC PATCH 12/14] repack: implement incremental MIDX repacking Taylor Blau
2026-02-25  0:22 ` [RFC PATCH 13/14] repack: introduce `--write-midx=incremental` Taylor Blau
2026-02-25  0:22 ` [RFC PATCH 14/14] repack: allow `--write-midx=incremental` without `--geometric` 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=xmqq4in3xlvb.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 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.