Jump to content
  • Advertisement
Sign in to follow this  
Dario Oliveri

Impact of dynamic memory management in games

This topic is 2500 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

Wich is the impact of dynamic memory management in C++ when writing games?
Using pointers, shared pointers objects, safeness about that. Correct ways to do that.

I know there are many things that must taken into account:


Ease of debugging, performance, avoiding leaks.


Wich strategies should be implemented for example in a game engine or a game framework?

I'd like to listen your opinions about that and about most common implementations.

what about a comparison of:
-manual reference counting (drop, grab).
-SharedPointer<someclass>

?

Share this post


Link to post
Share on other sites
Advertisement
I'm not quite sure what you are asking. What do you mean by impact?

In general I follow these guidelines:
* Use shared_ptr when ownership is shared (don't pass shared_ptrs around unless you really are sharing ownership rather than temporary access).
* Use unique_ptr when there is a single owner.
* Favor const references over pointers.
* Only allocate on heap when necessary.

Share this post


Link to post
Share on other sites
Personally I like to preallocate buffers and have some simple manager like class that I can
tell to add and remove objects for example, this is so I dont need to use "new" and "delete"
while also having continous memory for better loop iterations.

Shared pointers dont magically makes every problem go away, I still
strongly know what entity owns the resource and it gets notified when to free it.
I see shared pointers more as an added layer of safety regarding missing to free memory
and it works better with the rest of the std library.

Share this post


Link to post
Share on other sites
I tend to use dynamic allocation when I know I will be implementing a single instance of an object that will be used for a duration of time. Generally, you want to keep dynamic memory allocations of any kind to a minimum, as new() and delete() are expensive operations.

Share this post


Link to post
Share on other sites
How you setup the memory management per item is less important than how you "use" the memory overall. What I mean by this is that you can use whatever you want to control the allocations be it raw pointer, custom reference counting + smart pointers, shared_ptr, intrusive_ptr etc. Do what makes the most sense to you. What will generally kill your overall engine behavior is the per-frame allocation and deletion of memory. It is important to consider the usage patterns to avoid the continual memory churn. For instance, an object system could generally get away with using simple alloc/free as this happens fairly rarely in the overall picture of things. But, a particle system would be a huge problem if the individual particles are allocated and free'd constantly instead of using a reusable pool.

Other examples of where this can cost a lot overall, let's say you use strings internally for tagging up various information. If you have to manipulate strings constantly it is extremely bad news for an engine. Using std::string with a little work can be viable, basically replace the allocator with a call into a scratch memory system which ignores "delete" calls. Then, at the end of the frame, reset the entire scratch memory (a single pointer change) so you don't have to do all the small new/delete calls.

Knowing the usage patterns and selectively replacing new/delete with pools, scratch systems, etc is your primary defense against performance issues overall. As always though, start out as simple as possible and run performance analysis. With memory management though, things are not simply "time it" based as memory management is an aggregate issue which doesn't show up in a single location normally and simply makes everything slow down a little at a time. Overriding new/delete globally and adding counters is generally the first step, if you see a lot of new/delete per frame, you should probably identify the sources and consider better memory usage patterns via pools, scratch etc.

Without more specific information, this is about as general an overview as you could start with.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!