[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220919110829.GA2158779@port70.net>
Date: Mon, 19 Sep 2022 13:08:29 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: baiyang <baiyang@...il.com>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: The heap memory performance (malloc/free/realloc) is
significantly degraded in musl 1.2 (compared to 1.1)
* baiyang <baiyang@...il.com> [2022-09-19 15:53:30 +0800]:
> Hi there,
>
> As we have discussed at https://github.com/openwrt/openwrt/issues/10752. The malloc_usable_size() function in musl 1.2 (mallocng) seems to have some performance issues.
>
> It caused realloc and free spends too long time for get the chunk size.
how is malloc_usable_size related to free and realloc performance?
>
> As we mentioned in the discussion, tcmalloc and some other allocators can also accurately obtain the size class corresponding to a memory block and its precise size, and it is also very fast at the same time.
unlike musl those implementations don't return exact size nor have the
same security and memory fragmentation guarantees, so bad comparision.
tcmalloc:
// Returns the actual number N of bytes reserved by tcmalloc for the pointer
// p. This number may be equal to or greater than the number of bytes
// requested when p was allocated.
//
// This function is just useful for statistics collection. The client must
// *not* read or write from the extra bytes that are indicated by this call.
jemalloc:
<para>The <function>malloc_usable_size()</function> function
returns the usable size of the allocation pointed to by
<parameter>ptr</parameter>. The return value may be larger than the size
that was requested during allocation. The
<function>malloc_usable_size()</function> function is not a
mechanism for in-place <function>realloc()</function>; rather
it is provided solely as a tool for introspection purposes. Any
discrepancy between the requested allocation size and the size reported
by <function>malloc_usable_size()</function> should not be
depended on, since such behavior is entirely implementation-dependent.
>
> Can we make some improvements to the existing malloc_usable_size algorithm in mallocng? This should significantly improve the performance of existing algorithms.
can you give an actual interesting workload where that's
the bottleneck?
given that calling this function is almost always a bug
in production code, it's hard to see how it can cause
performance problems.
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.
