From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/9] reftable: introduce macros to grow arrays
Date: Thu, 01 Feb 2024 08:30:32 -0800 [thread overview]
Message-ID: <xmqqbk902llj.fsf@gitster.g> (raw)
In-Reply-To: <ZbtIQ3Hk6Mgvkv4j@tanuki> (Patrick Steinhardt's message of "Thu, 1 Feb 2024 08:29:07 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> Very good point indeed. I don't think peak memory usage is really all
> that helpful either because the problem is not that we are allocating
> arrays that we keep around all the time, but many small arrays which are
> short lived. So what is telling is the total number of bytes we end up
> allocating:
True. sum of requested sizes to all the calls to malloc() and
friends to allocate, ignoring what gets free()d in between, is what
would show how much we try to consume.
> Allocating 21 times as many bytes with our default growth factor should
> be a much more compelling argument why we don't actually want to use it
> compared to the 2% speedup.
;-).
next prev parent reply other threads:[~2024-02-01 16:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 8:00 [PATCH 0/9] reftable: code style improvements Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-01-31 17:44 ` Eric Sunshine
2024-01-31 20:35 ` Junio C Hamano
2024-02-01 7:29 ` Patrick Steinhardt
2024-02-01 16:30 ` Junio C Hamano [this message]
2024-01-31 8:01 ` [PATCH 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-01-31 17:55 ` Eric Sunshine
2024-01-31 8:01 ` [PATCH 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-01-31 8:01 ` [PATCH 9/9] reftable/record: improve semantics when initializing records Patrick Steinhardt
2024-02-01 7:32 ` [PATCH v2 0/9] reftable: code style improvements Patrick Steinhardt
2024-02-01 7:32 ` [PATCH v2 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-02-01 7:32 ` [PATCH v2 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-02-05 15:48 ` Karthik Nayak
2024-02-06 6:10 ` Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-02-01 16:15 ` Toon Claes
2024-02-02 5:21 ` Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-02-01 7:33 ` [PATCH v2 9/9] reftable/record: improve semantics when initializing records Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 0/9] reftable: code style improvements Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-02-06 6:35 ` [PATCH v3 9/9] reftable/record: improve semantics when initializing records Patrick Steinhardt
2024-02-06 9:10 ` [PATCH v3 0/9] reftable: code style improvements 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=xmqqbk902llj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--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.