3 ms·
what you say is true; the major gain for TCMalloc is in multi-(native)-threaded apps. I think this is pretty key, because otherwise TCMalloc is somewhat of an
by jwilliams 18y ago
what you say is true; the major gain for TCMalloc is in multi-(native)-threaded apps.
I think this is pretty key, because otherwise TCMalloc is somewhat of an overhead. Depending on your platform, a standard malloc with will pull ahead (depends on how favourable locking is, but it is the case for OS X anyway).
A multi-threaded instance sounds interesting, but - I'm guessing it would be a challenge to get a representative sample.
- tmm1 18y agohttp://goog-perftools.sourceforge.net/doc/tcmalloc-opspersec.vs.size.1.threads.png http://goog-perftools.sourceforge.net/doc/tcmalloc-opspersec...
- ice799 18y agoYou might be reading the article too literally -- you can test more than just tcmalloc, of course (ned, ptmalloc*, libumem, etc). It is -very- possible that one of these allocators will handle our memory footprint more gracefully than say, libc. There is only one way to find out: via A/B testing. I think the important thing to keep in mind is that assertions like: "I think this is pretty key, because otherwise TCMalloc is somewhat of an overhead." are a bit subjective, IMHO. Allocators are different from one another, and of course they react to a series of allocations/deallocations differently. We're trying to find out if the way we use our heap is better suited to another allocator like tcmalloc, or nedmalloc, or whatever. And RE: multi-threaded - I don't believe it will be particularly difficult to get a representative sample, but working on that isn't very high on my list right now.