
Glibc Enables a Per-Thread Cache for Malloc – Big Performance Win - jjuhl
http://www.phoronix.com/scan.php?page=news_item&px=glibc-malloc-thread-cache
======
jjuhl
More details: [https://sourceware.org/ml/libc-
alpha/2017-01/msg00452.html](https://sourceware.org/ml/libc-
alpha/2017-01/msg00452.html)

------
mtanski
All I can say is finally. Such a shame that the default malloc on most Linux
systems was so far behind in terms of performance (jemalloc/tcmalloc) for more
then a decade now.

I wonder how long it'll take for this implementation to shake out the many
bugs (fragmentation issues / worse case behavior) the early version of
jemalloc/tcmalloc suffered from.

------
kazinator
Well, big performance win for applications whose developers let malloc be the
major bottleneck.

~~~
wbl
Systems should make malloc fast so I don't have to write my own wrapper. Sure,
in some cases I know a lot more, but why confuse the heck out of valgrind when
I don't have to.

~~~
kazinator
No malloc optimization can eliminate the waste of re-initializing an object
from scratch. The fastest caching will be caching of almost-ready-to-go
objects that don't require allocation and initialization from scratch. No
malloc can provide that while sticking with malloc semantics.

