Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: realloc() - frequency, conditions, or experiences about
 relocation?
Date: Mon, 17 Jun 2024 15:21:24 +0200
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <v4pd8l$m519$1@dont-email.me>
References: <v4ojs8$gvji$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Jun 2024 15:21:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fe0891cf9321877d7d070b255a029de4";
	logging-data="726057"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18eEZO575jvtDRJNaRZ8do7"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:wgdljxK8H/T0ErZqxclWGIjhl8A=
In-Reply-To: <v4ojs8$gvji$1@dont-email.me>
X-Enigmail-Draft-Status: N1110
Bytes: 2460

On 17.06.2024 08:08, Janis Papanagnou wrote:
> In a recent thread realloc() was a substantial part of the discussion.
> "Occasionally" the increased data storage will be relocated along
> with the previously stored data. On huge data sets that might be a
> performance factor. Is there any experience or are there any concrete
> factors about the conditions when this relocation happens? - I could
> imagine that it's no issue as long as you're in some kB buffer range,
> but if, say, we're using realloc() to substantially increase buffers
> often it might be an issue to consider. It would be good to get some
> feeling about that internal.

Let me add...

I'd assume that there's some basic allocation size defined; some
simple test sample with a handful of bytes didn't relocate the data.
Yet I don't know whether allocated memory is managed sequentially
or has linked blocks. A peek info the source code might help. What
I found is this comment for extending chunks:[*]
       * Extending forward into following adjacent free chunk.
       * Shifting backwards, joining preceding adjacent space
       * Both shifting backwards and extending forward.
       * Extending into newly sbrked space
Going to investigate that source code[*] later...

Janis

[*] https://elixir.bootlin.com/glibc/glibc-2.1.2/source/malloc/malloc.c
(line 3077 ff)