[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3cfa744-2860-8a1e-6446-da4a703b48cc@ispras.ru>
Date: Tue, 20 Sep 2022 21:26:10 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.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 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
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.
