[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmeS-YcpfwtziQRMp-oH0jtEcdqn36WneNCBs4W6eGpeyoLKA@mail.gmail.com>
Date: Tue, 20 Sep 2022 13:44:56 -0400
From: Siddhesh Poyarekar <siddhesh@...hat.com>
To: baiyang <baiyang@...il.com>
Cc: Florian Weimer <fweimer@...hat.com>, Rich Felker <dalias@...c.org>, musl <musl@...ts.openwall.com>
Subject: Re: Re: The heap memory performance (malloc/free/realloc) is
significantly degraded in musl 1.2 (compared to 1.1)
On Tue, Sep 20, 2022 at 1:28 PM baiyang <baiyang@...il.com> wrote:
>
> > Is there any other valid reason to use
> > malloc_usable_size instead of simply using realloc?
>
> Yes, we use it as one of the parameters to estimate the memory copy cost when realloc degenerates back to malloc+memcpy+free, refer to the previous mails.
I was only pulled into this conversation with the email I responded
to; I am not subscribed to the musl mailing list. If this estimation
is not for diagnostics then it's really not that different from the
case I'm talking about. You shouldn't have to do this check and
realloc should do the right thing whenever there's space available in
the chunk. I can't comment on musl-specific bits because I haven't
taken a close enough look at mallocng to do that. In general though,
I don't think it makes sense for a C library to support
malloc_usable_size beyond diagnostics.
Sid
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.
