4 replies to this topic

[DemonRad]

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>

?

[colinhect]

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.

[Kristoffer Lindström]

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.

[ButchDean]

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.

[AllEightUp]

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.