Alex Rivera | Logout

One big pool or several type specific pools?

Asked 2009-12-27T00:10:21.123
9

I'm working on a video game which requires high performance so I'm trying to setup a good memory strategy or a specific part of the game, the part that is the game "model", the game representation.

I have an object containing a whole game representation, with different managers inside to keep the representation consistent, following the game rules. Every game entity is currently generated by a type-specific factory, so I have several factories that allow me to isolate and change the memory management of those entities as I wish.

Now, I'm in the process of choosing between those two alternatives:

  1. Having a memory pool for each type: that will allow really fast allocation/deallocation and minimal fragmentation as an object pool already know the size of the allocated objects. One thing that bother me is to have several pools like that that are separate, maybe making the other solution more efficient...
  2. Having one big memory pool shared by all factories of one game representation : (using something like boost::pool with some adapter functions) that way I've got all the game objects memory allocated together and can have one bit allocation for a game that I already know the total size (it's not always the case). I'm not sure it's a better solution than A because of possible fragmentation inside the pool, as there would be objects of different size in the same pool, but it looks like an easier one for memory analysis and other problem fixing.

Now, I had some real worlds experiences with the A so I'm not experienced with B and would like some advice regarding those solutions, for a long-life project. Which solution seem better for a long-life project and why? (Note: a pool is really necessary in this case because the game model is used for game editing too so there will be lot of allocation/deallocation of little objects).

Edit for clarification: I'm usin

Edit
Report

1 Answer

4

One problem that you'll run into is that STL implementations are allowed to assume that two allocators of the same type are equivalent. This is the reason that Boost.Pool uses only one pool (technically it uses a different pool for each type). I.E., your allocators are not allowed to have any non-static members in the general case. If you're making a video game and you know that your STL implementation does not have this problem, then don't worry about this -- however there might still be some issues with list::splice and std::swap on containers.

answered 2009-12-27T01:09:40.910

Your Answer