> So what you're actually trying to do is more clear now.

> And this is something that you should do on the “application layer”,

> not expect the libc to magically taking care of this.

Yes, we just do this at the application layer with the help of APIs such as malloc_usable_size. You can look at the previous emails, isn't that what we're discussing?

> They want to know if realloc will resize the allocation in-place so

> the internal memcpy will not happen.

> AIUI, what they really need is not "usable_size", but "cost estimation

> for resizing allocation at pointer P to size S". Which I believe they

> try to deduce from malloc_usable_size.

Yes, from malloc_usable_size, the size that the application layer actually needs to copy, and other parameters like the OS, allocator, etc.

Best Regards
BaiYang
baiyang@gmail.com
http://i.baiy.cn

**** < END OF EMAIL > ****

From: Alexander Monakov

Date: 2022-09-21 02:26

To: musl

CC: Quentin Rameau; Florian Weimer

Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)

On Tue, 20 Sep 2022, Rich Felker wrote:

> Exactly. This can be done entirely at the application layer just by

> keeping track of the size you allocated. In the above example, the

> number 256 kB is a red herring. Yes the

> "malloc(300KB)+memcpy(256KB)+free(256KB)" is wasteful, but the

> "malloc(300KB)+memcpy(200KB)+free(200KB)" would be comparably wasteful

> when you only want to preserve the first 2K, and you can make the

> decision that it would be wasteful, and that you instead just want to

> allocate a new buffer yourself and memcpy 2K, just by knowing the

> original 200KB, without any knowledge of malloc_usable_size.

They want to know if realloc will resize the allocation in-place so

the internal memcpy will not happen.

AIUI, what they really need is not "usable_size", but "cost estimation

for resizing allocation at pointer P to size S". Which I believe they

try to deduce from malloc_usable_size.

Alexander