On Mon, 14 Sep 2009 12:47:00 -0400, "James Bremner" <ravenspoint@yahoo.com> wrote:
Yes. This provided a significant performance improvement, however it has
some serious drawbacks
a.. I experienced some crashes during testing b.. Commercial licensing is expensive c.. It 'hooks' system calls to malloc, a technique I consider dodgy. d.. It is a DLL, which I avoid since they result in endless configuration management nightmares.
I completely share your views on Hoard. I don't like the hook placed on the allocator and it's just too much expensive for an allocator that makes program crash. Have you had a look at jemalloc? It's the allocator from FreeBSD. That's what they use for Firefox. It needs some adjustments, I guess, to be transformed into a full fledged STL allocator but it's a nice start. http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/jemalloc.c
Gosh! Did I suggest anything like this? However, a well designed multithreaded program will slow down, rather than speed up, on a multi-processor machine when the standard memory allocator is used which took me, at least, completely by surprise and mystified me for several days.
Sorry I misunderstood your mail. The main reason you get such a speed boost with a better allocator is because it can prevent (or at least reduce) false sharing and is able to allocate in different threads simultaneously. If you want to go further, go for concurrent/lockfree containers. -- EA