Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)

[Szabolcs Nagy <nsz@port70.net>]

* baiyang <baiyang@gmail.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.