At various times I've profiled some CPU bound code and thought malloc is taking too much time. This has led me to read up on, and try and develop various usage

At various times I've profiled some CPU bound code and thought malloc is taking too much time. This has led me to read up on, and try and develop various usage-optimised allocators. The one lesson I've learnt is that in most cases the standard libc allocator is actually extremely good. Where I have had big advantages over libc malloc is where the memory allocations have been specific to a thread context. For example, consider a multi-threaded server, where by you could guarantee that only one thread was active in a connection at anyone time. It's quite easy for a single connection to spend 5-10% of it's time in malloc and there are often big globalish locks around general purpose allocators, so it's easy to get get mutex contention which is far worse than the overhead of a sub-efficient allocator. In such cases you often need to have small bits of memory within the context of a connection. Here I found big benefits my mallocing memory in bug chunks and then simply splitting that up into small sections within a connection specific allocator to avoid any malloc mutex locking. What I've found is that in order to beat normal malloc, I think you really have to have a specific usage case that restricts something to do better.