[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2022092104455700962839@gmail.com>
Date: Wed, 21 Sep 2022 04:45:59 +0800
From: baiyang <baiyang@...il.com>
To: "Gabriel Ravier" <gabravier@...il.com>,
musl <musl@...ts.openwall.com>
Cc: "Quentin Rameau" <quinq@...th.space>,
"Florian Weimer" <fweimer@...hat.com>
Subject: Re: Re: The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
> At this point it feels more and more like malloc basically can't fulfill your needs unless every implementation out there starts adding specialized methods for your application. In other words, it might be more productive for you to simply bring in a more agreeable allocator, instead of trying to get every single allocator out there to bow down to your needs.
Yes, we will adapt as many allocators as possible to make our software more portable and adaptable.
Frankly, so far, we've only encountered malloc_usable_size performance issues with musl's mallocng (and, as we discussed earlier, this performance issue affects both realloc and free).
Of course, we also respect and understand the author's considerations and trade-offs, and have avoided calling malloc_usable_size for musl's mallocng in our software.
Thanks :-)
--
Best Regards
BaiYang
baiyang@...il.com
http://i.baiy.cn
**** < END OF EMAIL > ****
From: Gabriel Ravier
Date: 2022-09-21 04:33
To: musl; baiyang
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 9/20/22 20:35, baiyang wrote:
> 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.
At this point it feels more and more like malloc basically can't fulfill your needs unless every implementation out there starts adding specialized methods for your application. In other words, it might be more productive for you to simply bring in a more agreeable allocator, instead of trying to get every single allocator out there to bow down to your needs.
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
