Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: realloc() - frequency, conditions, or experiences about
 relocation?
Date: Tue, 18 Jun 2024 06:12:36 +0100
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <v4r504$16npo$1@dont-email.me>
References: <v4ojs8$gvji$1@dont-email.me> <875xu8vsen.fsf@bsb.me.uk>
 <v4ovqf$j5hq$1@dont-email.me> <87zfrjvqp6.fsf@bsb.me.uk>
 <v4pb4v$lhgk$1@dont-email.me> <87h6dr16md.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 Jun 2024 07:12:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cba6eb24be5a0db449e57ccf4e727e7c";
	logging-data="1269560"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Ad20qp3LCI+KWC9pBx6yGe3EEimANu+4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4yZS0NC2wXBXxP72OJStLtEYbM4=
In-Reply-To: <87h6dr16md.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 3325

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