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>]

Hi Alexander,

> > 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.

I see.

But then I doubt this is something you can reliably expect from any
implementation, as at best, one would just have to assume that the target
allocator works in one way and wouldn't change.
This will result in a code tightly bound to a specific alocator
because of the assumptions made about the library internals.

This is not really the kind of contract one makes with the POSIX/C library
in a portable way.

So if the request really is to press every libc implementation into
adopting one user's (or a few) self-made requirements,
that still doesn't sound like a constructive conversation here.

At this point if ones really needs micro-management of their memory,
they should just implement their own allocator.