Should you avoid memory allocation and deallocation while the game is running?

Question

I recently read this answer on this site, which says the following:

making sure no allocation/deallocation is being done while the game is running is a golden rule of thumb.

I interpret this as meaning that you should do all the necessary heap allocation while the game is booting up, and arrange it in object pools that you then manage when the game is running. Is this statement correct? The reason I'm struggling to understand it is because I thought that that goes against one of the main reasons we use dynamic heap allocation in games.

That I know of, there are three main uses for using dynamic allocation on the heap:

1. You have data whose size cannot be know at compile time and needs to be dynamically allocated at runtime.
2. You need to store objects that take up a large amount of space and won't fit on the stack
3. You have data whose lifetime outlives the current scope and thus must be stored on the heap.

I was under the impression that one of the main reasons for heap storage being used in games was reason 1, that you can't know the size of data collections beforehand and therefore need to work with dynamic memory. But if all the heap data should be allocated while the game is booting up, then that can't be true.

So does this mean that the reason we use heap storage in games is actually just reason 2 and 3?

Answer 1

I interpret this as meaning that you should do all the necessary heap allocation while the game is booting up, and arrange it in object pools that you then manage when the game is running. Is this statement correct?

Whenever you read that there is a "golden rule" which should "always" be followed, you should raise an eyebrow. Software engineering is more of an art than a science. Even the most recommended best practice is only the best course of action most of the time.

Allocating and deallocating memory a lot while the game is running can have a performance cost due to reducing memory locality. That performance cost could result in a measureable effect on framerate. That framerate could get too low for the game to be playable for some people in your target demographic.

But none of that will happen all the time. Not every game will turn into a slideshow the moment it has a tiny malloc in the main loop.

Object pools are a performance optimization. But it is an optimization which comes with costs. They require work to implement. The code gets more convoluted. Startup time might get longer. And you either impose an artificial limitation on how many objects you want to allow or need additional logic to change the pool size at runtime, which can cause performance hickups itself.

Whenever you consider to take a performance optimization measure, ask yourself:

• Do I actually need the performance?
• Will it actually have a measurable benefit in my particular situation?
• What is the cost of that performance optimization, now and for the future?
• Is the benefit worth that cost?

So focus on creating a playable game first, then worry about the performance.

Experienced programmers are able to anticipate certain performance problems in advance and avoid them in the first place by implementing patterns which mitigate them from the beginning. But anticipating which parts of your software architecture will eat how much performance when implemented in what way requires a lot of experience. So when you are still a beginner (less than 10 years of programming experience) you should rather implement in the most straight-forward way first, measure performance and optimize afterwards.