Custom memory allocators

A custom memory allocator will allocate a large segment of memory once, and then allocate pointers within that block of memory in response to allocation requests. So, how can we use this basic scheme to improve memory allocation performance?

We could indeed do it if we could relieve some of the requirements that the general-purpose memory manager has to observe, as in the following:

• Only create objects of fixed size or/and instances of specific classes.
• Do not support multithreading.
• Do not support the releasing of objects.
• LIFO allocation/deallocation order.

Because such an allocator would be very specialized, it could have an edge over general-purpose global allocators. Additionally, as their implementation can be really simple, such allocators offer a potential for inlining that won't ever be the case with a generic allocator. Second, we can control and avoid the memory fragmentation, optimize the memory locality, and even control the alignment for SIMD operations. And at last, as we preallocated our memory at the start, we will avoid the kernel calls that could be made by a general allocator to get fresh memory! So, summing up, the advantages are as follows:

• Fast and simple implementation
• Good memory locality and no memory segmentation
• No unexpected trips to kernels

This looks like a clear win! So, should we always use custom memory allocators for our classes? Sorry to disappoint you, but probably not if your program isn't allocating thousands and thousands of objects on the fly! Having said that, there are cases where we can use it to a good measure.