We’re seeing texture counts reported from the profiler as high as 1400 textures in scenes that just have some simple UI elements. Surely this can’t be correct. And if it is correct, why is it that high?
Our material count seems to be reported as much more than it should be as well. When doing a simple instancing of about 20 materials (via Renderer.materials property) and then destroying the instances, the profiler reports about 200 instances created and destroyed, rather than just 20.
I thought maybe this was the work of the editor caching materials/textures. Upon restarting the editor and loading a fresh, simple scene, the profiler reports slightly less materials and textures, but it’s still much more than what would seem normal.
Does anyone have any insight on this? It would be nice to know why we are seeing such high numbers because we are trying to reduce our batches and setpasses. It makes it fairly difficult when the numbers we are seeing seem to be so wildly inaccurate.
I know, 5 years old thread, but still in 2020 I have this question!
I just noticed, that the texture count also lists ALL textures in the project, including completely unused textures from imported asset pack / packages etc. Hope that doesn’t affect the Build in the end, but I guess while building it strips off all the unused files?
Number in the Editor are different from what you would see in the Player.
In the Editor the count includes alive and not collected by AssetGC assets. When you build Player we build only what is actually used by scene and added to Resources folder.
You can use Memory Profiler package to see memory usage map.
In the Editor the picture is quite different due to the Editor using materials and assets to draw itself.
Also there are couple of materials used implicitly by settings - e.g. skybox.
When profiling in the Editor would you rather want to see “game only” stats?
In unity 2021.3.9f1 using the profiler recorder this seems to be inaccurate as well? I have a simple scene with a cube and a light, texture count is 373? Furthermore, dynamically creating and releasing textures increases the texture count indefinitely (but does free the memory). The texture count seems to reset (to the usual 373) once a new scene is loaded.
Is all this expected behaviour? In that case what is the reasoning behind this? It is confusing to me.
Note that I am profiling on an iOS device, and not in the editor - using the Profiler Recorder API.
Have you tried taking Snapshots with the Memory Profiler Package at these moments to see what Textures it captures at being in memory at each of these moments? The Texture count resetting on level load speaks for normal behavior of runtime created objects that aren’t Destroy ()ed, shown with the Status of Leaked Dynamically Runtime Created Assets in the Selection Details panel. Level load triggers Resources.UnloadUnusedAssets which collects these.
Also it might be good to check if the snapshot would list out in more detail what these 373 Textures are.
It could be a bug but it’d be good to confirm with more details.
No. The way the Editor and Playmode are build right now, with all the conveniences for Editing and testing without having to make a build, works because the memory of the two are deeply shared. Separating these cleanly is therefore far from trivial.
So in general, with this architecture in place, the best that the Memory Profiler could do to clarify what is there due to the running scene in Playmode is to show by what each object is predominantly held in memory. That still isn’t trivial but a bit more achievable. Though we have no concrete plans or ETA for this yet.
That would still paint a somewhat muddy picture as the sizes of e.g. Textures would still be different than in a build, all of the Editors memory would still be captured alongside it and affect the different views in the profiler and also be reflected in the overall memory state, and not everything would be clean cut held by either Playmode or Editor (e.g. static fields could hold on to something and might not be used in a build etc)
So even with that feature, the cleanest picture of actual memory usage is only attainable by profiling a build on the target platform.
What is the benefit of having half accurate info with the default built in profiler? This applies to the memory profiler as well. The editor is extremely expensive on almost every stat which makes the profiler’s info (deep profiler included) completely useless because I can’t even deduct the editor’s stats from main game stats.
There’s no benefit to it from a profiling perspective, except for faster iteration times. Aside from that, the profiler’s usability for the use case of Playmode profiling suffers for the benefit of the general ease of use of the Editor so to speak. There’s some things that can be done on the profiler side to reduce the negative side of that, but there is a limit to it based on the overall architecture of the Editor that can’t be passed without a major overhaul of elements that are quite fundamental.