> - items are guaranteed to be packed tightly in memory, general allocators sometimes need to keep some housekeeping data next to the actual item memory > - it

> - items are guaranteed to be packed tightly in memory, general allocators sometimes need to keep some housekeeping data next to the actual item memory > - it’s easier to keep ‘hot items’ in continuous memory ranges, so that the CPU can make better use of its data caches These are huge advantages. Memory managers tend to keep pools for specific allocation ranges, eg, a pool for < 24 bytes, a pool for <= 64, etc up to, say, a megabyte after which it might be delegated to the OS, such as VirtualAlloc on Windows, directly. This is hand-wavy, I'm speaking broadly here :) This keeps objects of similar or the same sizes together, but it does _not_ keep objects of the same type together, because a memory manager is not type-aware. Whereas this system keeps allocations of the same type contiguous. You can do this in C++ by overriding operator new, and it's possible in many other languages too. I've optimised code by several percent by taking over the allocator for specific key types, and writing a simple and probably unoptimised light memory manager which is effectively a wrapper around multiple arrays of the object size which keeps object memory in pools for that type, and therefore close in memory. I can go into more detail if anyone's interested!