I am quite interested into the topic, and made a comparation between glibc and musl with following code:
#define MAXF 4096 void* tobefree[MAXF]; int main() { long long i; int v, k; size_t s, c=0; char *p; for (i=0; i<100000000L; i++) { v = rand(); s = ((v%256)+1)*1024; p = (char*) malloc(s); p[1023]=0; if (c>=MAXF) { k = v%c; free(tobefree[k]); tobefree[k]=tobefree[--c]; } tobefree[c++]=p; } return 0; }
```
The results show signaficant difference.
With glibc, (running within a debian docker image)
# gcc -o m.debian -O0 app_malloc.c
# time ./m.debian real 0m37.529s user 0m36.677s sys 0m0.771s
With musl, (runnign within a alpine3.15 docker image)
# gcc -o m.alpine -O0 app_malloc.c
# time ./m.alpine real 6m 30.51s user 1m 36.67s sys 4m 53.31s
musl seems spend way too much time within kernel, while glibc hold most work within userspace.
I used perf_event_open to profile those programs:
musl profiling(total 302899 samples) shows that those "malloc/free" sequence spend lots of time dealing with pagefault/munmap/madvise/mmap
But glibc profiling (total 29072 samples) is way much lighter, pagefault is the most cost while glibc spend significat time on "free"
It seems to be me, glibc make lots of uasage of cache of kernel memory and avoid lots of pagefault and syscalls.
Is this performance difference should concern realworld applications? On average, musl actual spend about 3~4ns per malloc/free, which is quite acceptable in realworld applications, I think.
(Seems to me, that the performance difference has nothing to do with malloc_usable_size, which may be indeed just a speculative guess without any base)