Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Inaccurate Texture/Material Counts in Profiler

Discussion in 'General Graphics' started by dburden1, Jul 22, 2015.

  1. dburden1

    dburden1

    Joined:
    Jan 29, 2015
    Posts:
    19
    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.
     
  2. dburden1

    dburden1

    Joined:
    Jan 29, 2015
    Posts:
    19
    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.
     
  3. TheSwanCollective

    TheSwanCollective

    Joined:
    May 6, 2016
    Posts:
    26
    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?
     
    alexeyzakharov likes this.
  4. Brad-Newman

    Brad-Newman

    Joined:
    Feb 7, 2013
    Posts:
    185
    I have a scene with:
    1. A camera
    2. A light
    3. A sphere with a Standard material (no texture)

    Profiler > Memory Profiler reports:

    Textures: 373 / 77.8 MB
    Meshes: 25 / 0.9 MB
    Materials: 35 / 46.0 KB
    AnimationClips: 0 / 0 B
    AudioClips: 0 / 0 B
    Assets: 1572
    GameObjects in Scene: 11
    Total Objects in Scene: 181
    Total Object Count: 1753
    GC Allocations per Frame: 326 / 14.0 KB


    I'm confused what this data means? I would expect it to be:
    Textures: 0
    Meshes: 1
    Materials: 1
    GameObjects in Scene: 3
    Total Objects in Scene: 3


    How can you effectively profile a scene to see how many materials are in memory?

    As a workaround, I've been running this in Update to see the materials:

    Code (CSharp):
    1. Material[] materials = FindObjectsOfType<Material>();
    2. Debug.Log("Materials: " + materials.Length);
     
    Last edited: May 9, 2020
    alexeyzakharov likes this.
  5. alexeyzakharov

    alexeyzakharov

    Joined:
    Jul 2, 2014
    Posts:
    507
    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?
     
    MartinTilo likes this.
  6. michael_unity145

    michael_unity145

    Joined:
    Mar 8, 2022
    Posts:
    21
    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.
     
  7. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,431
    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.
     
  8. AdamandEveStudios

    AdamandEveStudios

    Joined:
    Apr 19, 2022
    Posts:
    20
    Yes. Has this "game only" stats been added yet?
     
  9. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,431
    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.
     
    Last edited: May 25, 2023
    AdamandEveStudios likes this.
  10. AdamandEveStudios

    AdamandEveStudios

    Joined:
    Apr 19, 2022
    Posts:
    20
    I see. Good to know.

    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.
     
  11. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,431
    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.
     
    AdamandEveStudios likes this.