[dahart]

Custom allocators were needed, and often still are, in order to have enough memory in the first place (for example memory pools for specific sized small allocations are common), to avoid fragmentation that could lead to out-of-memory conditions or the need to defrag over time, to have control over how the free list regains memory and how long it takes. It’s important in a real-time or embedded application to prioritize predictability over some of the host OS’s goals, and to have stronger guarantees.

IIRC I think one of the primary reasons the EASTL was developed is because the STL at the time did not allow overriding the default built-in memory allocator, and because STL did a bunch of memory allocation.

This is changing and games use lots more STL and dynamic memory allocation than they used to, but a decade ago and earlier, STL use was generally discouraged for the same reason that any and all heap allocations were discouraged for gameplay and engine code: because doing heap allocations during real-time and in performance critical sections can impact performance significantly, and can be dangerous. This is still very true today: the first rule of high performance is to avoid dynamic memory allocations in the inner loop -- true in JavaScript, CUDA, C++, even Python. Dynamic memory allocations can sneak up on you too. It might seem small or innocuous until it piles up or pushes you over a threshold or hits some kind of lock condition.

One mentality I learned game programming that can be counter-intuitive at first is how and when to reserve the maximum amount of memory you need for a given feature and never change it. It can feel at first like you’re hogging way too much, or that something’s wrong with coding that way, but it’s much more predictable, can be much higher performance, and it can be safer for the overall system to ensure that you will never have a weird condition where several things all need more memory than expected at the same time and it suddenly crashes.