From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>
Subject: Re: [PATCH v2 7/8] reftable/merged: really reuse buffers to compute record keys
Date: Thu, 28 Dec 2023 09:03:00 -0800 [thread overview]
Message-ID: <xmqq8r5ei7jv.fsf@gitster.g> (raw)
In-Reply-To: <6313f8affdc136b183c1bd411d481efe5c676aee.1703743174.git.ps@pks.im> (Patrick Steinhardt's message of "Thu, 28 Dec 2023 07:28:04 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> In 829231dc20 (reftable/merged: reuse buffer to compute record keys,
> 2023-12-11), we have refactored the merged iterator to reuse a set of
> buffers that it would otherwise have to reallocate on every single
> iteration. Unfortunately, there was a brown-paper-bag-style bug here as
> we continue to release these buffers after the iteration, and thus we
> have essentially gained nothing.
s/-style// perhaps. It took me more than just reading of the above
but I needed to see the code before noticed that you are talking
about strbuf_release(). Only after that I think I understood what
you meant as a bug.
With the change, instead of using a new "entry_key" strbuf for
each iteration, the code now passes mi->entry_key to
reftable_record_key(), which will reuse the existing .buf member
of the strbuf to avoid reallcation. But releasing the strbuf in
each iteration defeats such optimization.
I suspect that a Git developer who will be reading "git log" output
in 6 months and finds the above paragraph understands the problem
and its fix better if the description hinted strbuf_reset() near
where it mentions "release", something like:
... to reuse a pair of long-living strbufs by relying on the
fact that reftable_record_key() tries to reuse its already
allocated .buf member by calling strbuf_reset(), which should
give us significantly fewer reallocation compared to the old
code that used on-stack strbufs that are allocated for each and
every iteration. Unfortunately, we called strbuf_release() on
these long-living strbufs that we meant to reuse, defeating the
optimization.
or along that line, perhaps?
Other than that, a very reasonable fix. Thanks for a pleasant read.
> Fix this performance issue by not releasing those buffers on iteration
> anymore, where we instead rely on `merged_iter_close()` to release the
> buffers for us.
>
> Using `git show-ref --quiet` in a repository with ~350k refs this leads
> to a significant drop in allocations. Before:
>
> HEAP SUMMARY:
> in use at exit: 21,163 bytes in 193 blocks
> total heap usage: 1,410,148 allocs, 1,409,955 frees, 61,976,068 bytes allocated
>
> After:
>
> HEAP SUMMARY:
> in use at exit: 21,163 bytes in 193 blocks
> total heap usage: 708,058 allocs, 707,865 frees, 36,783,255 bytes allocated
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> reftable/merged.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/reftable/merged.c b/reftable/merged.c
> index 556bb5c556..a28bb99aaf 100644
> --- a/reftable/merged.c
> +++ b/reftable/merged.c
> @@ -128,8 +128,6 @@ static int merged_iter_next_entry(struct merged_iter *mi,
>
> done:
> reftable_record_release(&entry.rec);
> - strbuf_release(&mi->entry_key);
> - strbuf_release(&mi->key);
> return err;
> }
next prev parent reply other threads:[~2023-12-28 17:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 9:17 [PATCH 0/7] reftable: fixes and optimizations (pt.2) Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 1/7] reftable/stack: do not overwrite errors when compacting Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 2/7] reftable/writer: fix index corruption when writing multiple indices Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 3/7] reftable/record: constify some parts of the interface Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 4/7] reftable/record: store "val1" hashes as static arrays Patrick Steinhardt
2023-12-20 9:25 ` Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 5/7] reftable/record: store "val2" " Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 6/7] reftable/merged: really reuse buffers to compute record keys Patrick Steinhardt
2023-12-20 9:17 ` [PATCH 7/7] reftable/merged: transfer ownership of records when iterating Patrick Steinhardt
2023-12-20 19:10 ` [PATCH 0/7] reftable: fixes and optimizations (pt.2) Junio C Hamano
2023-12-28 6:27 ` [PATCH v2 0/8] " Patrick Steinhardt
2023-12-28 6:27 ` [PATCH v2 1/8] reftable/stack: do not overwrite errors when compacting Patrick Steinhardt
2023-12-28 6:27 ` [PATCH v2 2/8] reftable/stack: do not auto-compact twice in `reftable_stack_add()` Patrick Steinhardt
2023-12-28 6:27 ` [PATCH v2 3/8] reftable/writer: fix index corruption when writing multiple indices Patrick Steinhardt
2023-12-28 6:27 ` [PATCH v2 4/8] reftable/record: constify some parts of the interface Patrick Steinhardt
2023-12-28 6:27 ` [PATCH v2 5/8] reftable/record: store "val1" hashes as static arrays Patrick Steinhardt
2023-12-28 17:03 ` Junio C Hamano
2023-12-28 6:28 ` [PATCH v2 6/8] reftable/record: store "val2" " Patrick Steinhardt
2023-12-28 6:28 ` [PATCH v2 7/8] reftable/merged: really reuse buffers to compute record keys Patrick Steinhardt
2023-12-28 17:03 ` Junio C Hamano [this message]
2023-12-28 6:28 ` [PATCH v2 8/8] reftable/merged: transfer ownership of records when iterating Patrick Steinhardt
2023-12-28 17:04 ` Junio C Hamano
2024-01-03 6:22 ` [PATCH v3 0/8] reftable: fixes and optimizations (pt.2) Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 1/8] reftable/stack: do not overwrite errors when compacting Patrick Steinhardt
2024-02-14 15:12 ` Han-Wen Nienhuys
2024-02-15 7:43 ` Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 2/8] reftable/stack: do not auto-compact twice in `reftable_stack_add()` Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 3/8] reftable/writer: fix index corruption when writing multiple indices Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 4/8] reftable/record: constify some parts of the interface Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 5/8] reftable/record: store "val1" hashes as static arrays Patrick Steinhardt
2024-02-05 11:39 ` Karthik Nayak
2024-02-06 6:03 ` Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 6/8] reftable/record: store "val2" " Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 7/8] reftable/merged: really reuse buffers to compute record keys Patrick Steinhardt
2024-01-03 6:22 ` [PATCH v3 8/8] reftable/merged: transfer ownership of records when iterating Patrick Steinhardt
2024-02-05 13:08 ` [PATCH v3 0/8] reftable: fixes and optimizations (pt.2) Karthik Nayak
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=xmqq8r5ei7jv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=hanwenn@gmail.com \
--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).