What does HackerNews think of tcmalloc?

> * Switching from libc malloc to tcmalloc (dating myself a little bit)

If you think of tcmalloc as an old crusty allocator, you've probably only seen the gperftools version of it.

This is the version Google now uses internally: https://github.com/google/tcmalloc

It's worth a fresh look. In particular, it supports per-CPU caches as an alternative to per-thread caches. Those are fantastic if you have a lot more threads than CPUs. I haven't checked if it's been adapted for the latest upstream kernel API, but there's also the idea of "vcpu"-based caches: basically rather than a physical cpu id, it's an (optionally per-numa-node-based) dense id assigned to active threads, so that it still works well if you have a small cpu allocation for this process on a many-core machine.

cache alignment also gets stupid complicated when you add in what kind of malloc you use, c.f. google's tcmalloc: https://github.com/google/tcmalloc

> Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?

Yup [0].

There's even other complete libraries like tcmalloc [1] and jemalloc [2].

[0] https://stackoverflow.com/a/262481/1111557

[1] https://github.com/google/tcmalloc

[2] https://github.com/jemalloc/jemalloc

I'm interested in this as well. I'm sure there's more to it than this, but I know there are multiple implementations of malloc out there:

- https://github.com/google/tcmalloc

- https://github.com/jemalloc/jemalloc

Have you seen the recently updated GitHub project: https://github.com/google/tcmalloc