[musl] Re: realloci(): A realloc() variant that works in-place

[Thiago Macieira]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251111/47325b5a/attachment.sig>