DOD — Unity Memory Best Practices — Part 3

Ideal Memory Allocations

Ideally our memory allocation should look something like this:

In this case we allocate all the common data first: things like menus, object pools and common items.

Then when we load each level, we only allocate the data needed for that level.

Here is another way to visualize it:

At startup our memory usage is zero.

Note — the heap also includes the executable and any static data, but this is data we cannot change so we’ll ignore it for this example.

When we reach our main menu, we have allocated all the memory that we need to run the game that is not specific to a particular level. Stuff like object pools and common items.

After that, when entering level 1, we allocate only the memory required to run level 1.

While playing in level 1, we are not allocating any new memory. All the memory needed to run level 1 has already been allocated when we loaded it.

When exiting level 1, we deallocate all the memory used by the level. If we load and unload level 1 thousands of times, our Main Menu memory usage should not change.

Therefore when playing through multiple levels, our memory should look like this:

Every time we return to the main menu we are back to using the same amount of memory.

Aside from reducing memory fragmentation, there is another reason we want to allocate all our memory at once: to reduce the chance the game will crash due to lack of memory during gameplay.

The reasons are:

1. It’s easier to catch out-of-memory issues during development.
   QA just needs to run the game, or load a particular level, instead of guessing at which point in the gameplay the most memory is used.
2. It’s really hard to catch out-of-memory issues in the wild.
   Users have different phones, and are running different apps in the background, therefore each user will have a different amount of free memory available. That means users will crash at different points in the game. That makes it very difficult to figure out why those crashes happened and if a fix actually solved the problem.
3. You don’t want users to randomly crash during gameplay.
   If a user reports that they crashed in the middle of playing, you’ll have a really hard time figuring out if it’s a logic bug or a memory issue. You’ll need to figure out exactly what the user did and try to replicate it internally. That’s a huge waste of time compared to simply knowing that the game failed on load.
4. It’s a worse experience for users to crash in the middle of the game.
   If a user crashes in the middle of the game, they’ll have a much harder time figuring out what happened. If the game crashes in the middle of gameplay, the user will think the gameplay is buggy. Even worse, users will lose their progress, then they might crash again and again every time they try to replay the level.

There is another reason why we want to allocate our memory in chunks, and that reason is the Garbage Collector, covered in Part 4.

Part 4 — https://medium.com/@nitzanwilnai/dod-unity-memory-best-practices-part-4-1c409d20a1d1