Hacker News Reader

Comment by thrownaway2424 | Hacker News Reader

Comparison to tcmalloc suspiciously omitted.

Came here to say just that. tcmalloc performs better than jemalloc in various cases.

Interesting - I had noticed the omission, but I had assumed that meant that jemalloc had emerged as the agreed-upon allocator best for production. Are you aware of any recent published experiments with the two?

tcmalloc is great for small random sized allocations. when using std::string without .reserve() it performed much better from the testing I've done last year.

I'm not aware of any serious published works. Really the only way to choose an allocator is to try them all on your benchmark workload. Any other benchmarks are likely to be irrelevant.

I think tcmalloc vs. jemalloc is basically a wash. One is written by google people and the other is written by facebook people. Facebook is much more forward about their open source project than is Google, so more people have heard of jemalloc.

jemalloc is unaffiliated with FB. It was developed and integrated into FreeBSD and Firefox long before the author started working for Facebook.

What I meant about facebook's advocacy is that they have published lots of high profile blogs and whatnot about applications of jemalloc which have contributed greatly to its renown relative to tcmalloc, and I think it's fair to say that jemalloc versions 2, 3, and 4 have been largely underwritten by the Big Thumb.

And the other side of what I was trying to say is that for Google it's largely an issue of personality. tcmalloc is Google's malloc. JE works for Facebook. If JE worked at Google I'm sure Google would just use jemalloc.

Reply on news.ycombinator.com