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

[Quentin Rameau <quinq@fifth.space>]

> This is a good thing, we noticed it before. But we actually need a realloc that **can specify the copy range**.
> 
> As in our previous example, suppose we "void* p malloc(200KB)" and "malloc_usable_size(p)" returns 256KB. For allocators such as tcmalloc, if we do "realloc(p, 300KB)", it will actually execute "malloc(300KB)+memcpy(**256KB**)+free(256KB)". But at this time, the actual business of the application layer often only needs to copy a small amount of content, such as the first 2KB of data.

So what you're actually trying to do is more clear now.
And this is something that you should do on the “application layer”,
not expect the libc to magically taking care of this.

If your application already knows it only needs to keep back only a few amount of data, do this in a wrapper, malloc(300KB), memcpy(2KB), free old memory.
If on the other hand it know it actually wants to reuse the same data but in a more vast contiguous memory, use realloc.

> Therefore, it would be great if there were additional parameters to inform realloc to just execute malloc(300KB)+memcpy(**2KB**)+free(256KB) when degenerating back to malloc+memcpy+free.

That's what your wrapper would be.