threads / patch / 65193

patchbuiltin/help.c: move strbuf out of help loops

Subject: [PATCH] builtin/help.c: move strbuf out of help loops

## tl;dr

7 messages between Mar 10, 2026 and Mar 11, 2026. Diffs are folded; open one to read it.

replies: 6people: 4as markdown or json

Siddharth Shrimali· Mar 10, 2026, 07:03 UTC · lore

In list_config_help(), a strbuf was being initialized and released inside two separate loops. This caused unnecessary memory allocation and deallocation on every iteration.

Move the strbuf declaration to the top of the function and use strbuf_reset() inside the loops to reuse the same buffer. Similarly release() the buffer at the end of the function to free the memory. This improves performance by avoiding repeated heap pressure by reducing the number of allocations.

This also fixes a minor memory leak when the SHOW_CONFIG_HUMAN case triggers a continue.

Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
---
 builtin/help.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
Show changes to builtin/help.c +3 −4
diff --git a/builtin/help.c b/builtin/help.c
index 86a3d03a9b..07398b430e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -134,10 +134,10 @@ static void list_config_help(enum show_config_type type)
 	struct string_list keys = STRING_LIST_INIT_DUP;
 	struct string_list keys_uniq = STRING_LIST_INIT_DUP;
 	struct string_list_item *item;
+	struct strbuf sb = STRBUF_INIT;
 
 	for (p = config_name_list; *p; p++) {
 		const char *var = *p;
-		struct strbuf sb = STRBUF_INIT;
 
 		for (e = slot_expansions; e->prefix; e++) {
 
@@ -149,7 +149,6 @@ static void list_config_help(enum show_config_type type)
 				break;
 			}
 		}
-		strbuf_release(&sb);
 		if (!e->prefix)
 			string_list_append(&keys, var);
 	}
@@ -161,10 +160,10 @@ static void list_config_help(enum show_config_type type)
 
 	string_list_sort(&keys);
 	for (size_t i = 0; i < keys.nr; i++) {
+		strbuf_reset(&sb);
 		const char *var = keys.items[i].string;
 		const char *wildcard, *tag, *cut;
 		const char *dot = NULL;
-		struct strbuf sb = STRBUF_INIT;
 
 		switch (type) {
 		case SHOW_CONFIG_HUMAN:
@@ -195,13 +194,13 @@ static void list_config_help(enum show_config_type type)
 
 		strbuf_add(&sb, var, cut - var);
 		string_list_append(&keys_uniq, sb.buf);
-		strbuf_release(&sb);
 
 	}
 	string_list_clear(&keys, 0);
 	string_list_remove_duplicates(&keys_uniq, 0);
 	for_each_string_list_item(item, &keys_uniq)
 		puts(item->string);
+	strbuf_release(&sb);
 	string_list_clear(&keys_uniq, 0);
 }
 

-- 
2.51.2
Patrick Steinhardt· Mar 10, 2026, 12:41 UTC · re: Siddharth Shrimali · lore

Re: [PATCH] builtin/help.c: move strbuf out of help loops

On Tue, Mar 10, 2026 at 12:33:28PM +0530, Siddharth Shrimali wrote:
Show 34 quoted lines
> In list_config_help(), a strbuf was being initialized and released
> inside two separate loops. This caused unnecessary memory allocation
> and deallocation on every iteration.
> 
> Move the strbuf declaration to the top of the function and use
> strbuf_reset() inside the loops to reuse the same buffer. Similarly
> release() the buffer at the end of the function to free the memory.
> This improves performance by avoiding repeated heap pressure by reducing
> the number of allocations.
> 
> This also fixes a minor memory leak when the SHOW_CONFIG_HUMAN case
> triggers a continue.
> 
> Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
> ---
>  builtin/help.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/builtin/help.c b/builtin/help.c
> index 86a3d03a9b..07398b430e 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -134,10 +134,10 @@ static void list_config_help(enum show_config_type type)
>  	struct string_list keys = STRING_LIST_INIT_DUP;
>  	struct string_list keys_uniq = STRING_LIST_INIT_DUP;
>  	struct string_list_item *item;
> +	struct strbuf sb = STRBUF_INIT;
>  
>  	for (p = config_name_list; *p; p++) {
>  		const char *var = *p;
> -		struct strbuf sb = STRBUF_INIT;
>  
>  		for (e = slot_expansions; e->prefix; e++) {
>

What's missing from the context here is that the next line already knows to `strbuf_reset()`. You could do a trick and drop the empty newline here while at it, as that would then make the reset call visible.

Show 13 quoted lines
> @@ -149,7 +149,6 @@ static void list_config_help(enum show_config_type type)
>  				break;
>  			}
>  		}
> -		strbuf_release(&sb);
>  		if (!e->prefix)
>  			string_list_append(&keys, var);
>  	}
> @@ -161,10 +160,10 @@ static void list_config_help(enum show_config_type type)
>  
>  	string_list_sort(&keys);
>  	for (size_t i = 0; i < keys.nr; i++) {
> +		strbuf_reset(&sb);

Our coding style says that statements should come after variable declarations.

Other than that this patch looks good to me, thanks!
Patrick
Siddharth Shrimali· Mar 10, 2026, 16:00 UTC · re: Patrick Steinhardt · lore

[PATCH v2] builtin/help.c: move strbuf out of help loops

In list_config_help(), a strbuf was being initialized and released inside two separate loops. This caused unnecessary memory allocation and deallocation on every iteration.

Move the strbuf declaration to the top of the function and use strbuf_reset() inside the loops to reuse the same buffer. Similarly release() the buffer at the end of the function to free the memory. This improves performance by avoiding repeated heap pressure by reducing the number of allocations.

This also fixes a minor memory leak when the SHOW_CONFIG_HUMAN case triggers a continue.

Suggested-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
---
Changes in v2:
- Moved strbuf_reset() after variable declarations to follow 
  coding standards.
- Removed unnecessary empty lines to tighten the code as suggested 
  by Patrick.
 builtin/help.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
Show changes to builtin/help.c +3 −6
diff --git a/builtin/help.c b/builtin/help.c
index 86a3d03a9b..467a0763a6 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -134,13 +134,11 @@ static void list_config_help(enum show_config_type type)
 	struct string_list keys = STRING_LIST_INIT_DUP;
 	struct string_list keys_uniq = STRING_LIST_INIT_DUP;
 	struct string_list_item *item;
+	struct strbuf sb = STRBUF_INIT;
 
 	for (p = config_name_list; *p; p++) {
 		const char *var = *p;
-		struct strbuf sb = STRBUF_INIT;
-
 		for (e = slot_expansions; e->prefix; e++) {
-
 			strbuf_reset(&sb);
 			strbuf_addf(&sb, "%s.%s", e->prefix, e->placeholder);
 			if (!strcasecmp(var, sb.buf)) {
@@ -149,7 +147,6 @@ static void list_config_help(enum show_config_type type)
 				break;
 			}
 		}
-		strbuf_release(&sb);
 		if (!e->prefix)
 			string_list_append(&keys, var);
 	}
@@ -164,7 +161,7 @@ static void list_config_help(enum show_config_type type)
 		const char *var = keys.items[i].string;
 		const char *wildcard, *tag, *cut;
 		const char *dot = NULL;
-		struct strbuf sb = STRBUF_INIT;
+		strbuf_reset(&sb);
 
 		switch (type) {
 		case SHOW_CONFIG_HUMAN:
@@ -195,13 +192,13 @@ static void list_config_help(enum show_config_type type)
 
 		strbuf_add(&sb, var, cut - var);
 		string_list_append(&keys_uniq, sb.buf);
-		strbuf_release(&sb);
 
 	}
 	string_list_clear(&keys, 0);
 	string_list_remove_duplicates(&keys_uniq, 0);
 	for_each_string_list_item(item, &keys_uniq)
 		puts(item->string);
+	strbuf_release(&sb);
 	string_list_clear(&keys_uniq, 0);
 }
 

-- 
2.51.2
Junio C Hamano· Mar 10, 2026, 20:33 UTC · re: Siddharth Shrimali · lore

Re: [PATCH v2] builtin/help.c: move strbuf out of help loops

Siddharth Shrimali <r.siddharth.shrimali@gmail.com> writes:
> In list_config_help(), a strbuf was being initialized and released
> inside two separate loops. This caused unnecessary memory allocation
> and deallocation on every iteration.

OK. strbuf_init() followed by a loop that does strbuf_reset() followed by use of strbuf, concluded with strbuf_release() after leaving the loop, is a fairly common pattern to optimize such a use pattern.

> This also fixes a minor memory leak when the SHOW_CONFIG_HUMAN case
> triggers a continue.
Does it?  You are essentially saying that
	for (int i = 0; i < 10; i++) {
		struct strbuf sb = STRBUF_INIT;
 
		switch (SHOW_CONFIG_HUMAN) {
                case SHOW_CONFIG_HUMAN:
			continue;
		}
	}

leaks, but a strbuf merely initialized can safely be discarded without leaking any resources, can't it?

Show 14 quoted lines
> diff --git a/builtin/help.c b/builtin/help.c
> index 86a3d03a9b..467a0763a6 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -134,13 +134,11 @@ static void list_config_help(enum show_config_type type)
>  	struct string_list keys = STRING_LIST_INIT_DUP;
>  	struct string_list keys_uniq = STRING_LIST_INIT_DUP;
>  	struct string_list_item *item;
> +	struct strbuf sb = STRBUF_INIT;
>  
>  	for (p = config_name_list; *p; p++) {
>  		const char *var = *p;
> -		struct strbuf sb = STRBUF_INIT;
> -

A blank between the variable declaration block and the first statement makes the code easier to follow. Loss of a blank line here is of dubious value.

>  		for (e = slot_expansions; e->prefix; e++) {
> -
This removal is good.
>  			strbuf_reset(&sb);
So we first reset, and then start building things in sb.
Show 9 quoted lines
>  			strbuf_addf(&sb, "%s.%s", e->prefix, e->placeholder);
>  			if (!strcasecmp(var, sb.buf)) {
> @@ -149,7 +147,6 @@ static void list_config_help(enum show_config_type type)
>  				break;
>  			}
>  		}
> -		strbuf_release(&sb);
>  		if (!e->prefix)
>  			string_list_append(&keys, var);

We no longer have to release it inside the loop, as we will reset at the beginning of the next iteration.

Show 8 quoted lines
>  	}
> @@ -164,7 +161,7 @@ static void list_config_help(enum show_config_type type)
>  		const char *var = keys.items[i].string;
>  		const char *wildcard, *tag, *cut;
>  		const char *dot = NULL;
> -		struct strbuf sb = STRBUF_INIT;
> +		strbuf_reset(&sb);
>

The arrangement of the blank line is wrong here. The original was the last line of a declaration block which should come before the blank. Now you are removing it, and then adding a strbuf_reset() as the first statement, which should come after the blank that delimits the declarations and statements.

In any case, here we have a second loop that wants to use a scratch strbuf, so again we reset it at the beginning of the loop before we use it.

Show 8 quoted lines
>  		switch (type) {
>  		case SHOW_CONFIG_HUMAN:
> @@ -195,13 +192,13 @@ static void list_config_help(enum show_config_type type)
>  
>  		strbuf_add(&sb, var, cut - var);
>  		string_list_append(&keys_uniq, sb.buf);
> -		strbuf_release(&sb);
>  
And we no longer release it during iteration.  Instead ...
Show 6 quoted lines
>  	}
>  	string_list_clear(&keys, 0);
>  	string_list_remove_duplicates(&keys_uniq, 0);
>  	for_each_string_list_item(item, &keys_uniq)
>  		puts(item->string);
> +	strbuf_release(&sb);
... we release after we leave the loop.
>  	string_list_clear(&keys_uniq, 0);
>  }

Having looked at this patch, I recall somebody else is revamping this function already, so this patch would step on their toes. Please pay attention to what is going on in the project around the code you are touching, and coordinate with others who are working on the same code if necessary.

https://lore.kernel.org/git/20260228104654.80831-2-amishhhaaaa@gmail.com/
Thanks.
Siddharth Shrimali· Mar 11, 2026, 18:13 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] builtin/help.c: move strbuf out of help loops

On Wed, 11 Mar 2026 at 02:03, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Having looked at this patch, I recall somebody else is revamping
> this function already, so this patch would step on their toes.
> Please pay attention to what is going on in the project around the
> code you are touching, and coordinate with others who are working on
> the same code if necessary.
>
> https://lore.kernel.org/git/20260228104654.80831-2-amishhhaaaa@gmail.com/
>
> Thanks.
Hi Junio (CC'ing Amisha),

After looking at the refactor of list_config_help() in the other active thread, I agree that my optimization is no longer necessary.

Amisha's new structure with set_config_vars() and set_config_sections() is much cleaner. Since the logic is now encapsulated in these helpers, my proposed changes would not be applicable.

I'll drop this patch and focus on my other contributions. Thanks for the guidance!

Regards, Siddharth

Amisha Chhajed· Mar 11, 2026, 19:30 UTC · re: Siddharth Shrimali · lore

Re: [PATCH v2] builtin/help.c: move strbuf out of help loops

Show 7 quoted lines
> After looking at the refactor of list_config_help() in the
> other active thread, I agree that my optimization is no longer
> necessary.
>
> Amisha's new structure with set_config_vars() and set_config_sections()
> is much cleaner. Since the logic is now encapsulated in these helpers,
> my proposed changes would not be applicable.

I feel removing out the strbuf initialisation and release out of the loop is still applicable, I have added all the parts in v5 which were not fixed by my improvements and tagged you, check it out here https://lore.kernel.org/git/20260311192151.60489-1-amishhhaaaa@gmail.com/

-- 
Thanks,
Amisha
Junio C Hamano· Mar 11, 2026, 19:48 UTC · re: Amisha Chhajed · lore

Re: [PATCH v2] builtin/help.c: move strbuf out of help loops

Amisha Chhajed <amishhhaaaa@gmail.com> writes:
Show 14 quoted lines
>> After looking at the refactor of list_config_help() in the
>> other active thread, I agree that my optimization is no longer
>> necessary.
>>
>> Amisha's new structure with set_config_vars() and set_config_sections()
>> is much cleaner. Since the logic is now encapsulated in these helpers,
>> my proposed changes would not be applicable.
>
> I feel removing out the strbuf initialisation and release out of the
> loop is still applicable,
> I have added all the parts in v5 which were not fixed by my
> improvements and tagged you,
> check it out here
> https://lore.kernel.org/git/20260311192151.60489-1-amishhhaaaa@gmail.com/

I love seeing two community members, both of which are relatively newcomers, working well together ;-).

← back to recent threads