I am developing a game for PDAs, if you know anything about them you know their memory allocators are super slow and suck, so I need a custom memory allocator. A drop in replacement for new/delete would be ideal, and which doesn't use STL. I have found a few but they seem really big and complicated. Memory Pool System (MPS) http://www.ravenbrook.com/project/mps/ - can't use open source Hoard http://www.hoard.org/ - way too big and complicated, open source BGET http://www.fourmilab.ch/bget/ - best one ive found yet, open license, only 2 source files boost::pool http://boost.org/libs/pool/doc/index.html - can't replace new/delete, only good for set sizes of objects Are there any others I should be looking at? Should I roll my own? FYI the memory I'll be allocating mostly consists of around 4 different sizes (classes) but I'll also need small random allocations. Maybe a hybird pool system would be best, have set pools for the most used sizes, then everything else would use the random size allocator.

Quote:I am developing a game for PDAs, if you know anything about them you know their memory allocators are super slow and suck, so I need a custom memory allocator.

Is this true?

Perhaps your allocation patterns cause that.

If you're talking about replacing global new and delete, then there is little benfit to be gained - your allocator will need to be generic.

If you truly want to improve performance, then look into actual allocation patterns.

If all you need is a small number different classes, then look into any fixed size allocator, and override the new operators on these classes. The implementation can then simply create a pool that allocates memory using platform allocator, but keeps the memory in a stack when such objects are released, and re-uses it when it needs to create new objects. This way, you get optimal memory use without the problems of pre-allocated storage.

For allocation of arbitrary memory chunks, look into allocation patterns again. How are they allocated and released? Sequentially? In random order? In reverse order?

If sequentially, then ring buffer is your optimal choice.

If randomly, then look if any benefit is to be gained from allocating fixed size chunks of size equalling maximum chunk size, and translating the problem back to fixed size allocation.

Custom memory allocators aren't a silver bullet.

Also, is your game multi-threaded? Most allocators aren't thread safe. And this can come to haunt you back much later.

A much greater benefit from custom allocation comes from reducing fragmentation.

Yeah I think you guys are right, I will try boost::pool on my main used classes, it looks pretty easy to use. After thinking about it more fragmentation is probably a problem right now.

After creating 5 pools for my most used objects my startup allocations went from over 17,000 to around 3,000. That should go a long way to reducing memory fragmentation on the PDA. I also reduced the average number of runtime allocations from 30-40/frame to 1-2/frame.