> To my knowledge there is no allocator which does chunk merging on 500k chunks in the default configuration.
It can be ANY size, "500KB" is just an example.

> musl 1.1.x never did block merging on objects of this size.
Yes, we known it, and we will evaluate according to the specific situation of the operating system, libc implementation and allocation size. Again, this is not the point of this discussion.

> In the absence of a concrete, quantitative report of how it's impacting performance, definitely no.
OK, I understood and thanks for your time.
 
--

   Best Regards
  BaiYang
  baiyang@gmail.com
  http://i.baiy.cn
**** < END OF EMAIL > **** 
 
 
From: Rich Felker
Date: 2022-09-20 04:28
To: baiyang
CC: musl
Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
On Tue, Sep 20, 2022 at 04:17:20AM +0800, baiyang wrote:
> > Clearly you did not measure this, because with basically any
> > real-world malloc, it will call mremap and move the memory via
> > MMU-level remapping, with no copying involved whatsoever.
> 
> OK, I've been said multiple times: 
> > ...and the chance of merging chunks (small blocks) or **mremap**
> > (large blocks) in the underlayer realloc.
 
To my knowledge there is no allocator which does chunk merging on 500k
chunks in the default configuration.
 
> > ...evaluate the cost (including the possibility of realloc using
> > block merging like in musl 1.1, and techniques like **mremap** to
> > avoid copying)
 
musl 1.1.x never did block merging on objects of this size.
 
> Therefore, we determined that the possibility of each memory
> allocator calling mremap in different situations was specifically
> considered on the LINUX platform.
> 
> And I mentioned it before: we did massively optimize performance in
> real-world applications. These are not the focus of our discussion.
> 
> So now it is certain that in musl mallocng:
> 1. malloc_usable_size will always just return the size submitted by
> the user to malloc, not the actual size allocated inside it, right?
 
Yes.
 
> 2. We have no plans to improve malloc_usable_size performance yet, right?
 
In the absence of a concrete, quantitative report of how it's
impacting performance, definitely no.
 
Even if there is such a report, if the source of the problem is that
you're gratuitously trying to second-guess realloc and making your
program slower, rather than just calling realloc, it's not a very
interesting report. malloc_usable_size is *not* a function whose use
is recommended and it's only there at all because we can't remove an
interface once adding it.
 
If the problem is actually the size determination in realloc and free,
and if you've *measured* that and can make a quantitative report on
how it affected *real world usage* not a made-up benchmark, then that
is potentially actionable.
 
Rich