I’m working in 6.2. Once I measured and find that RAM consumption of the app increased from 500 to 800 for no reason, after minor changes.
I’ve started the investigation and find the problematic commit (and the last ‘stable’ right before it). It had multiple minor changes (like assets renaming, asmdef renaming, new input system). But before that I’ve built without addressables/textures and find that there’s no impact on RAM. So, after cherry-picking the last stable commit, I’ve done changes from the “unstable” step by step. Finally I reached the point where all changes were applied, but RAM still was fine (500mb). I’ve taken a memory snapshot from the “unstable” version and captured a new on “stabled” and compared them both. What I’ve found:
There was drastic changes:
“UIElements” +54к, different rows like, UIR.RenderData и StyleProperty and so on (I don’t use the new UI in my game)
“Style” +40k
“TextCore” +10k
“Glyph” +4k
“String” +333k, +40mb. Different strings like “scanning device” or “log”, unable to unfold them old
I have to mention that I haven’t added new plugins except Input System or assets with 333k strings. Also I find the string “<type fullname="UnityEngine.MonoBehaviour" preserve="all" />” in the link file of new builds. The project includes Zenject, addressables, UniTask, DoTween, Steamworks plugins and builds il2cpp on win64.
UPD. Also during compilation progress used to stuck on “Deserealizing” or dropped some “netcode” error offering to debug it with the VS.
UPD2. The problem remains on 6.3.11 and 6.4.0
2 Likes
After upgraded to unity 6, tons of my players suffering this issue.
1 Like
Any news? It’s 3 months passed
Updated to 6.3.6f1 “LTS”, the problem still remains: the game consumes overwhelming RAM, +37%
Your best best is to submit a bug report to get someone at Unity to look at this.
1 Like
I suspect the tags on this thread were a bit too general for anyone to see it and pick it up. I was about to add some more specific ones to give the appropriate teams a ping but then noticed the warning shown on your summary page: you’re comparing Editor snapshots.
Your game doesn’t need to use UI TK for that to show up if you capture the Editor instead of a built Player because the Editor is using it for it’s UI, including the Memory Profiler UI.
So to really understand why your built Player uses more memory between your two changesets, you need to make (at least) 2 builds, capture their memory usage and compare those. That’ll get rid of a whole bunch of noise that is only related to the Editor running around your play mode Player and offer more concrete pointers towards what’s going on here, including noise introduced through script recompilations and domain reload.
1 Like
Thanks for the reply! I’ve captured a build snapshot. Unfortunately, I can’t build the previous version.
Well, without a snapshot from the previous version we can’t really see what changed. But you could dig into what takes up memory now. The untracked amounts are difficult to get into without picking up a native platform profiler and the managed memory usage is pretty tame but you could dig deeper into Native and Graphics and see if anything there sticks out beyond what you’d expect.
