alt Hacker News> Every default malloc implementation worked this way about 12 years ago.
Perhaps "default" is doing the heavy lifting here. Glibc malloc was quite bad for a long time, true. But TCmalloc / jemalloc are 21-22 years old, respectively, and jemalloc has been the FreeBSD (released) default malloc implementation for the last 18.
> The solution is and always has been to make larger allocations and use those efficiently.
Having a not-dogshit allocator really doesn't hurt. There's no reason to defend shitty allocator + every application doing manual memory pools on top of it to paper over the bad allocator.
I'm not defending anything, I'm saying it's usually trivial to make allocation time marginal.
+ every application doing manual memory pools
Usually it's simple data structures in flat memory.
If allocation is taking all the time, that's a poorly optimized program with lots of low hanging fruit and a different allocator is not the right fix. It's like having a boat with a hole in the bottom and someone says the solution is a smaller hole.
But TCmalloc / jemalloc are 21-22 years old, respectively, and jemalloc has been the FreeBSD (released) default malloc implementation for the last 18.
jemalloc is also possibly bigger than all of musl. If it was a problem after optimization I would use it and I have in the past, it's just nowhere near as important as minimizing allocations in the first place. OpenBSD uses straight mmap.