Sign in to follow this  

Dynamic memory allocation overhead (C++)

This topic is 3862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone. I was designing the scene management base for a game engine, and I was relying heavily on dynamic memory allocation even for the smallest of objects. However, recently I started thinking about the performance and memory overheads incurred by each memory allocation. In particular, I would really appreciate any info (or links to info) on how the new and delete (or malloc and free) work - what exactly happens for each memory allocation and how the memory manager keeps track of stuff. Thanks in advance.

Share this post


Link to post
Share on other sites
Well, the short is that it's expensive. Most games spend a lot of time developing custom memory allocators to avoid this cost. The general algorithm is:

1) allocate a huge block of memory at startup
2) use placement new to allocate game objects directly into that memory (you dodge the actual allocation code but still get constructors called and whatnot.
3) free the memory on game shutdown

The reason you do this is to (1) avoid the OS overhead of allocating memory and (2) keep memory unfragmented.

This wikipedia article probably has some good nuts & bolts info:
http://en.wikipedia.org/wiki/Dynamic_memory_allocation

-me

Share this post


Link to post
Share on other sites
Doug Lea's malloc has a rather nice description of it's algorithms, and you can poke around the code too if you're feeling adventurous. Small allocations are often handled differently to large allocations in order to reduce the overhead (such as allocating fixed blocks with potential unused space but lower book-keeping information required for each block).

Share this post


Link to post
Share on other sites
If you are not up to the task of writing your own memory manager, a quick solution might be to try boost pools. From my experience, allocations via boost pool may end up as much as 10 times faster than ordinary malloc, but they come with their own set od disadvanteges. The pools allow you only fixed size allocations and they are fastest for smallest data sizes (PODs). Another great thing about boost pools is they can be used as allocators for STL containers.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
Doug Lea's malloc has a rather nice description of it's algorithms, and you can poke around the code too if you're feeling adventurous. Small allocations are often handled differently to large allocations in order to reduce the overhead (such as allocating fixed blocks with potential unused space but lower book-keeping information required for each block).
We actually use a modified version of this at work, which I've been poking around at...

Share this post


Link to post
Share on other sites
Thanks for the replies. I think I will go ahead and implement a simplistic memory manager. Since it will only be used inside the scene manager module, it shouldn't be very hard to implement. Evil Steve, I'm assuming since you didn't complain that it's doing its job efficiently then, right?

Share this post


Link to post
Share on other sites
Quote:
Original post by hikikomori-san
Thanks for the replies. I think I will go ahead and implement a simplistic memory manager. Since it will only be used inside the scene manager module, it shouldn't be very hard to implement. Evil Steve, I'm assuming since you didn't complain that it's doing its job efficiently then, right?
Yep, definitely. It is on a Nintendo DS though, which has much tighter memory and speed restrictions than a PC.

For something like a scene manager, I'd recommend allocating all object of the same type (and therefore size) out of a fixed pool if possible. That way the memory allocation is kept to a minimum. It might also be a good idea to look into Free Lists if you don't know what they are.

Share this post


Link to post
Share on other sites

This topic is 3862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this