I have a custom allocation scheme in my engine because I want my game to run fast and efficiently on mobile phones and consoles like OUYA. I wrote a custom STL allocater and so far every library I use hooks into my allocation system. However there are some libraries that don't support hooking custom allocaters into that I would like to use. So my question is basically this: should I take the extra effort to make sure that STL integrates perfectly with my allocaters and use as few external libs that can't hook into them as possible? Or should custom allocaters just be used for the game engine itself?

Some time ago I had a performance problem on my lowest-end supported devices (atom, FYI). I identified allocation as a problem. I rewrote the systems involved so I cut allocation count to 1/30.

I keep hearing about those custom allocators, but I wonder if all this people is really trying to minimize allocations in the first place, because this is what everyone should do first. Avoiding work. Not doing useless work faster.

Now, I'm not claiming people to be doing the wrong thing up start, it's just a question I have. Before trying to alloc faster, have you tried alloc'ing less frequently?

edit: typo.

That's a good point. Although my event system needs to make lots of allocations quickly. Maybe I could cut down on complexity if I just use custom allocation schemes in the areas I need them and not try to wrap everything in such a general purpose system.

The more allocation scenarios you use a custom allocator for, the closer it will degrade to general-purpose.

Profile first and foremost.

Allocate as little as possible.

For the remainder, decide on a specialized allocation strategy as much as possible. Does your event system really need a free-store style allocator, or can you get away with something like a stack allocator or a freelist/pool or some other mechanism?

Worst case, rearchitect your code to eliminate allocation overhead (while taking care not to introduce other forms of algorithmic overhead in the process).