Re: realloc() - frequency, conditions, or experiences about relocation?

On 18/06/2024 00:39, Keith Thompson wrote:

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]

We have a continuously growing buffer, and we want the best strategy
for reallocations as the stream of characters comes at us. So, given
we now how many characters have arrived, can we predict how many will
arrive, and therefore ask for the best amount when we reallocate, so
that we neither make too many reallocation (reallocate on every byte
received) or ask for too much (demand SIZE_MAX memory when the first
byte is received).?

[...]
 That's going to depend on the behavior of the implementations
realloc() function.
 malloc() and realloc() typically allocate more memory than they're
asked for, so that another realloc() call can often expand the
allocated memory in place.
 I have a small test program that uses realloc() to expand a 1-byte
allocated buffer to 2 bytes, then 3, then 4, and so on.  In one
implementation, in one test run, it reallocates at 25 bytes, and
then not again until just over 128 kbytes.  Other implementations
behave differently.
 A realloc() call that's able to return its first argument is likely
to be much quicker than one that does an actual reallocation.
If you want to fine tune for performance, you'll have to allow
for the implementation you're using, either by performing run-time
measurements or by analyzing the implementation (which could change
in the next release).
 Multiplying the size by 2 or 1.5 as needed is likely to be good enough.
 

A small test program can hog all of memory for itself, and so isn't a good test. What matters is where you're running something like a video game, and the artists stuff the comupter's memory full of artwork until it runs out, and then slowly and reluctantly remove their masterworks until the other routines have enough memory to run. So the game won't run out of memory, but only just. It's very tight.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc