CODEWITHSUNDEEP
memoryoptimizationunity-game-engineprofiling
agiro
agiro

Reputation: 2080

Unity profiling my scripts' memory usage

I took a look at the profiler when running my game and I can watch a whole bunch of stuff there - but not my scripts' memory usage. Thing is, my game's total mem allocation is 223 MB, but the textures are only 112 of this and one or two MB that I see except for that. I have no clue where my other 100 MB memory went and I would like to optimize my scripts a bit. Side note: I code using Visual Studio. Maybe I should look there?

Upvotes: 2

Views: 5690

Answers (1)

Ricky R
Ricky R

Reputation: 236

Here are a few memory profiling tips I have learned from shipping apps in Unity.

GC ALLOC

In the CPU Usage view of the Unity Profiler window you can see how much memory your script allocated in any given frame. This is shown in the GC Alloc (Garbage Collection Allocations) column.

This won't give you the total memory usage of a single script, but it is very useful for improving performance and memory consumption. If your scripts are allocating every single frame, memory will continue to accumulate until the Garbage Collector gets triggered. This accumulation will increase your memory footprint and running the GC will cause a performance hit.

See here for more info: https://docs.unity3d.com/Manual/ProfilerCPU.html

Memory View

The Detailed Memory View of the Unity Profiler Window tells you the memory usage of anything loaded in the game (including lots of built-in assets). This will let you identify which textures, meshes, or other assets are overly large. When you look at an asset in this view it tells you where it is referenced in your scene, which can help you identify which game objects may be using too much memory.

One problem with this view is that many assets show up as a blank because they don't have a name. This is happens when you create assets (textures, meshes, etc.) in script. You can change this by setting the .name property of any asset you create. This will then show up in the memory profiler window.

See here for more info: https://docs.unity3d.com/Manual/ProfilerMemory.html

Build Report

After you perform a build (Standalone, Windows Store, etc.) a build report is generated in the editor log. It can be hard to find, but it provides a lot of good information on what assets are contributing to your build size. One thing to remember is that this report uses uncompressed asset sizes, so many types of assets (textures in particular) will actually end up smaller than it shows here. In the upper-right corner of the console window, there's a drop-down menu for opening up the Editor logs. The part you are interested in will look something like this:

Textures      0.0 kb     0.0% 
Meshes        0.0 kb     0.0% 
Animations    0.0 kb     0.0% 
Sounds        0.0 kb     0.0% 
Shaders       18.6 kb    0.4% 
Other Assets  0.7 kb     0.0% 
Levels        5.2 kb     0.1% 
Scripts       460.8 kb   10.2% 
Included DLLs 3.9 mb     89.1% 
File headers  8.4 kb     0.2% 
Complete size 4.4 mb     100.0% 

Used Assets and files from the Resources folder, sorted by uncompressed size:
18.9 kb  0.4% Resources/unity_builtin_extra
4.0 kb   0.1% ...UnityEngine.UI.dll
1.8 kb   0.0% ...UnityEngine.Networking.dll
0.1 kb   0.0% ...UnityEngine.Advertisements.dll
0.1 kb   0.0% ...UnityEngine.Purchasing.dll
0.1 kb   0.0% Assets/TestClass.cs
0.1 kb   0.0% Assets/MemoryTester.cs
0.1 kb   0.0% Assets/Rotator.cs

For the lazy, there is a Unity addon in the asset store that can parse this for you: https://www.assetstore.unity3d.com/en/#!/content/8162

(I have neither used this addon nor endorse its use)

System.GC.GetTotalMemory

If you are developing on a Windows Desktop PC you can ask the system for the amount of memory it thinks is allocated for your app using System.GC.GetTotalMemory(...). The actually number it reports may not be of interest to you, but if you place calls to this function at various points in your app you can see when total memory usage goes up. For example, you might put a call to GetTotalMemory before a large block of initialization and then again at the end of the initialization. Comparing the two numbers give you an estimate of how much your memory grew*

*It may not be totaly accurate because there are processes going on in the background, like GC, that can affect this number

See here for more info: https://msdn.microsoft.com/en-us/library/system.gc(v=vs.110).aspx

Hope some of this helps!!

Upvotes: 5

Related Questions