* Jonathon Anderson: >> This assumes that memory allocation >> is actually a performance problem, otherwise you could let malloc >> handle the details. > > In our (Dyninst + HPCToolkit) work, we have found that malloc tends to > be slow in the multithreaded case, in particular with many small > allocations. The glibc implementation (which most of our clients use) > uses a full mutex to provide thread-safety. While we could do a lot > better in our own projects with regards to memory management, the fact > remains that malloc alone is a notable facet to the performance of > libdw.
Current glibc versions have a thread-local fast path, which should address some of these concerns. It's still not a bump-pointer allocator, but at least there are no atomics on that path. I'm not sure if it is prudent to code around imperfections in older allocators.
