The main problem with this approach for us is not throughput, MALLOC_ARENA_MAX is a maximum number of arenas per core, and our new servers have 48 cores, meaning we would still have a huge number of arenas and fragmentation problem. Yes, it will be a bit better but not even close to tcmalloc. There is a good post by Heroku with some tests of different MALLOC_ARENA_MAX, that can give more insight on performance hit. https://devcenter.heroku.com/articles/testing-cedar-14-memor...

I think, this particular part of the design is here for historical reasons. The classic way of allocating memory in Unix systems was heap extension with brk/sbrk calls, so glibc malloc from beginning was designed using these syscalls and logic. So with this mechanism you need to free last allocated object to shrink the heap. Now, allocators often get new memory from system using mmap syscall and probably have different expectations.

I've mentioned at the beginning of this article, that we already have several systems running with tcmalloc. So using jemalloc would mean that we would need to bring new dependency. Tcmalloc solves fragmentation issue really well for us, we can get estimation of how much memory is 'lost' due to fragmentation. We saw that potential saving from let's say jemalloc, cannot be higher than 1-3% of memory use and decided it's not worth to bring new dependency for so little value.

Applied on a Backend developer position, received a link to online test with algorithmic tasks (got 100% for these tasks on Codility), then had a Skype interview with their architect (just discussed my experience, nothing technical). After that haven't got neither email nor call. Would not recommend, don't waste your time.