Memory Manager

Why not write your own first, then compare it to another.

Mine will be done tomorrow night most likely; I am looking for something to compare it to.

Look up the enginuity articles here, it outlines one (and gives code). I think it's enginuity 3... possibly 2.

Depending on how big of a system you are writing, you may want to make free lists. Its like a memory manager, but you have a pool for each data type. That way you don't have to do any shifting of memory to keep things from getting too fragmented, there is only one size you can allocate in that pool. This is probably the fastest implementation of a memory manager.

I think free lists would be a good way to go about it, at least for things like commonly occuring game objects.

I'll assume we are talking about C++ here, so in that case i suggest doing 2 things, for dynamically allocating memory for small objects the generic memory manager kills performance and can easily fragment memory for this you can use a pooling scheme you don't need to write this your self as the loki library & boost library provide such a thing, with loki's small object allocator you can use it on a per-class basis and if the some of the objects are large the custom allocator forwards the request to the generic manager instead.

i did some profiling the other day found that dynamically allocating memory of small object with custom allocator specifically for small objects was nearly 3x better in performance than the generic memory manager (that was on VC++ 2k5).

For large instances you can just do a plain free-lists where when you delete memory you don't really deallocate the memory you just destruct it and mark the now uninitialized memory as free again, you need to seperate de/allocation and construction/destruction to do this efficently.

[Edited by - snk_kid on February 19, 2005 6:30:50 AM]

Quote:

Original post by okonomiyaki Look up the enginuity articles here, it outlines one (and gives code). I think it's enginuity 3... possibly 2.

My current memory manager was based upon this design; but if you read through the comments you can see that it's flawed in some areas dealing with the Heap. I haven't actually gotten into programming the engine itself it (just basic framework, strapped for time with school and because we haven't got a solid idea yet) so it's not *that* big of a problem yet; but it soon might be if I continue without using it.

Right now there is a global Memory Manager and anything that needs to be handled by it will just devrive the baseclass IMemoryObject and will be handled automagically. But as Eps said it could lead to fragmentation, and snk_kid said it could lead to performance loss?

So what would I exactly use in boost? Their auto_ptr implementations? I haven't gotten around to actually looking at the boost libraries yet.

The memory manager from FluidStudios is great. It's not an article, but I think also source code is worth to compare your own with.

FluidStudios Memory Manager

Already looked at the Fluid Studios stuff; I wasn't thrilled at looking at it, normally I want to understand what's going on when I put it in my code ;). It seems like a lot more than I need.