[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 22:33:32 +0200
From: Gabriel Ravier <gabravier@...il.com>
To: musl@...ts.openwall.com, baiyang <baiyang@...il.com>
Cc: Quentin Rameau <quinq@...th.space>, Florian Weimer <fweimer@...hat.com>
Subject: Re: 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.
