|
|
Message-ID: <5000379.OV4Wx5bFTl@tjmaciei-mobl5>
Date: Tue, 11 Nov 2025 19:50:53 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: Rich Felker <dalias@...c.org>
Cc: James Y Knight <jyknight@...gle.com>, Alejandro Colomar <alx@...nel.org>,
musl@...ts.openwall.com, The 8472 <the8472.rs@...inite-source.de>,
Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Tuesday, 11 November 2025 14:45:45 Pacific Standard Time Rich Felker wrote:
> And that's still going to happen. The only difference is the exact
> thresholds at which it happens, and having slightly less memory
> overhead along the way. If the problem is "moving objects is expensive
> and we don't want to do that", nothing on this path does anything to
> solve it.
It may postpone it, possibly indefinitely.
There are two unknowns with the algorithm dealing with container growth:
- the number of elements the user will ultimately add
- how much realloci() may grow
Because we don't and can't know those, it's very hard to predict how useful
this will be in general circumstances. I have experimented with giving a
number for the first, but I can't simulate the second without an actual
implementation.
The point is that there is a non-zero chance that in expanding the block we
save one or more malloc+move+free sequences. The most common would be the last
operation, when the user stops adding elements before the next reallocation,
which is also the costliest all reallocations.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.