Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been using jemalloc for over 10 years and don't really see a need for it to be updated. It always holds up in benchmarks against any new flavor of the month malloc that comes out.

Last time I checked mimalloc which was admittedly a while ago, probably 5 years, it was noticebly worse and I saw a lot of people on their github issues agreeing with me so I just never looked at it again.



Mimalloc v3 has just come out (about a month ago) and is a significant improvement over both v2 and v1 (what you likely last tested)


[flagged]


It still beat mimalloc when I checked 4-5 years ago.


You really need to benchmark your workloads, ideally with the "big 3" (jemalloc, tcmalloc, mimalloc). They all have their strengths and weaknesses.

Jemalloc can usually keep the smallest memory footprint, followed by tcmalloc.

Mimalloc can really speed things up sometimes.

As usually, YMMV.


I've benchmarked them every few years, they never seem to differ by more than a few percent, and jemalloc seems to fragment and leak the least for processes running for months.

Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing, so I am not inclined to trust it now.


> Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing

That’s… ahistorical, at least so far as I remember. It wasn’t marketed as either of those; it was marketed as small/simple/consistent with an opt-in high-severity mode, and then its performance bore out as a result of the first set of target features/design goals. It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.


> It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.

That is true of basically every single malloc replacement out there, that is not a uniquely defining feature.


mimalloc definitely made claims that could not be reproduced, or at least not by me. That's why I wrote this doc five years ago. "Irreproducible malloc benchmarks" https://www.dropbox.com/scl/fi/evnn6yoornh9p6l7nq1t9/Irrepro...


Look up the numbers in other comments above. When it comes to performance, the Google's tcmalloc is unconquered.


I tried all three, multiple times, and it depends.

Using the last workload tested as an example, mimalloc just consumed memory like crazy. It was probably leaking, as it was the stock version that comes in Debian, so probably quite old.

Tcmalloc and jemalloc were neck to neck when comparing app metrics (request duration etc... was quite similar), but jemalloc consistently used only about half of RAM as opposed to tcmalloc).

Both custom allocators used way less RAM than the stock allocator though. Something like 10x (!) less. In the end the workload with jemalloc hovers somewhere around 4% of the memory limit. Not bad for one single package and an additional compile option to enable it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: