I’m having a huge performance issue that I’m trying to solve somehow…
Has anyone faced this problem where GC.MarkDependencies takes a huge amount of CPU time? (see attached screenshot)
How it is happening: In my game, the maps (2D tile maps) are generated at Runtime, because the player can choose which set of maps he will explore. They are generated using Coroutines to keep the UI responsive (loading screen), but after loading, GC.MarkDependencies starts it’s job, but takes a really long time to complete, stealing precious frames (in my last profiling, it took 65 frames in my PC, an i7-2670QM, running inside a VM)
It is hidden inside the Loading.UpdatePreloading and, since it starts when I load my maps, I know I must change this loading somehow…
Map loading/generation do generate some garbage, about 60kb per map (still working on it), but I believe this would not cause the problem above…
When I say ‘generated’, I mean: creating the material, assigning the TileSet texture to it, creating the Mesh to support each Tile then UV mapping it accordingly to the desired Tiled Map (see Chaoseiro / X-UniTMX / wiki / Home — Bitbucket)
Things I still need to try:
Loading from Prefabs instead of generating at Runtime (I think this would be the solution, but want to hear thoughts from someone that also faced this problem)
Using Application.LoadLevelAdditiveAsync (I believe this would not help since GC.MarkDependencies fires after maps are loaded)
Something else I do not know yet
So, has anyone faced, and solved, this problem?
Is the Prefab route the probably solution?
I can try to explain better or give more information if needed
I find out the reason. remove the Resources.UnloadUnusedAssets. It can cause GCCollect many times, cost amount of CPU times in some Low side mobile phone. You can use Resources.UnloadAssets(“”); manually. This API can not cause GC.
After some years, finally came back to this project/problem, and this solves it
(I also did the whole prefab thing, but that was also needed for other optimizations)
I have a similar situation going where chunks of environment are being streamed at runtime, I’m using an asset for this called SECTR Stream from the store and apparently it calls Resources.UnloadUnusedAssets() as well. In some areas this was causing a 1800ms spike in the profiler. After getting rid of it no more spikes. Thanks so much for pointing this out Nick_lzn!
I’m having a spike of 150ms, right after LoadSceneAsync is done after first frame of the new scene this happens. I don’t see what I can do about it, how can I avoid “Resources.UnloadUnusedAssets” when i’m not calling it? I also use Incremental GC to avoid these kind of spikes.
From the game log:
“Unloading 144 unused Assets to reduce memory usage. Loaded Objects now: 2246.
Total: 82.161980 ms (FindLiveObjects: 0.188295 ms CreateObjectMapping: 0.040623 ms MarkObjects: 81.442011 ms DeleteObjects: 0.491050 ms)”
This is extra bad in my VR application and I’m stuck… It’s enough frames lost that OpenVR puts the user back in the “grid world environment”… Can’t have that.
Resources.UnloadUnusedAssets unloads native Unity assets from memory, keeping your games memory use down. If you just remove calls to it, you are potentially introducing a memory leak into your game.
Please run your game and monitor the memory in the profiler or the Task Manager to check if you have a memory leak. If you do, you will need to either manually unload assets one by one using Resources.UnloadAsset, or call UnloadUnusedAssets at a point where the user will not notice the hitch, such as during a loading screen.
I have 3 scenes, 1 referenced in the build and the other 2 are addressables that are loaded / unloaded from the first one.
These scenes each contain two buttons and a TextMeshPro input field.
On my decently configured PC, it takes 600ms.
On a OnePlus 7 Pro, 6-7k ms.
On a OnePlus 3T (2016) device, one of the frame takes between 12k and 14k ms.
According to the profiler, the responsible is GC.MarkDependencies. @Nick_lzn 's solution doesn’t work for me as the only places where Resources.UnloadAssets(); is called is in URP and TextMeshPro code. I still tried removing those calls and ran the profiler again, bearing the same results.
If anyone would have any idea what might be causing this, it’d be great.
EDIT: I was using Photon’s fusion networking api. I tried having the same setup without it and the issues went away. I know where to dig now.
To hopefully add some clarity to this thread let me quote my reply from this related thread :
Happy to answer any related questions as best I can. Also, the Memory Profiler package aims at clarifying the status and reasoning for objects to be retained in memory via the References and Selected Item Details sections. So if in doubt, give that a try