4 ms·

Yeah malloc() is pretty terrible in glibc by modern standards. For some workloads it just can't keep up and ends up fragmenting space in such a way that memory

Yeah malloc() is pretty terrible in glibc by modern standards. For some workloads it just can't keep up and ends up fragmenting space in such a way that memory can't be returned to the OS (and thus be used for the page cache) and you end up in this performance spiral. I always deploy C++ server on jemalloc. Been doing it for years and while there's been occasional hicks up when updating it has provided much more predictable performance.

throwaway2048 9y ago
This has nothing to do with glibc malloc()
- rurban 9y ago
  It has. It was never updated to ptmalloc3
kartD 9y ago
Actually from my understanding, it's libstdc++'s allocator that is causing the issue, not malloc.
- mtanski 9y ago
  A big reason the small object optimization exists in libstdc++ containers is because system malloc() is not fast enough. We're not talking about another optimization (small object / locality) as his issue was caused by libstdc++ alloc pools which would not need to exist in the first place if system malloc was better. So libstdc++ reinvents end up reinventing the wheel poorly. As the author mentioned, when he disabled the optimization behavior GLIBCPP_FORCE_NEW he ended up burning more CPU via system (glibc) malloc(). Once he added jemalloc on top of GLIBCPP_FORCE_NEW, this pretty much evened out with previous behavior runtime performance. The conclusion towards the end of article: > The right answer to "malloc is slow" is to make it faster.
  - jwakely 9y ago
    By default libstdc++ stopped using the pooling allocator in 2005: https://gcc.gnu.org/r106665 https://gcc.gnu.org/r106665 That's one year after the ancient, bitrotted, unofficial copy of the libstdc++ documentation that the blog post links to, but still ancient history.
- api 9y ago
  This is correct. Glibc malloc works fine, though jemalloc is faster in highly multithreaded code and seems to be slightly more memory efficient.

throwaway2048 9y ago

This has nothing to do with glibc malloc()

rurban 9y ago
It has. It was never updated to ptmalloc3

kartD 9y ago

Actually from my understanding, it's libstdc++'s allocator that is causing the issue, not malloc.

mtanski 9y ago
A big reason the small object optimization exists in libstdc++ containers is because system malloc() is not fast enough. We're not talking about another optimization (small object / locality) as his issue was caused by libstdc++ alloc pools which would not need to exist in the first place if system malloc was better. So libstdc++ reinvents end up reinventing the wheel poorly. As the author mentioned, when he disabled the optimization behavior GLIBCPP_FORCE_NEW he ended up burning more CPU via system (glibc) malloc(). Once he added jemalloc on top of GLIBCPP_FORCE_NEW, this pretty much evened out with previous behavior runtime performance. The conclusion towards the end of article: > The right answer to "malloc is slow" is to make it faster.
- jwakely 9y ago
  By default libstdc++ stopped using the pooling allocator in 2005: https://gcc.gnu.org/r106665 https://gcc.gnu.org/r106665 That's one year after the ancient, bitrotted, unofficial copy of the libstdc++ documentation that the blog post links to, but still ancient history.
api 9y ago
This is correct. Glibc malloc works fine, though jemalloc is faster in highly multithreaded code and seems to be slightly more memory efficient.