Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Thursday, June 8, for a Q&A with Unity's Content Pipeline group here on the forum, and on the Unity Discord, and discuss topics around Content Build, Import Workflows, Asset Database, and Addressables!
    Dismiss Notice
New Forum User Notice Content Pipeline Dev Blitz Day

Whats the difference between Transform and UnityEngine.Transform?

Discussion in 'Profiler Previews' started by TJHeuvel-net, Mar 15, 2022.

  1. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    787
    I was checking our profiles, and noticed these:


    upload_2022-3-15_11-4-50.png

    upload_2022-3-15_11-5-48.png

    upload_2022-3-15_11-5-21.png
    upload_2022-3-15_11-5-33.png

    I was just wondering, i highly doubt we have custom classes with the same names, so they must be from Unity. Why are there two Transforms and GameObjects?
     

    Attached Files:

    TJHeuvel-net, Mar 15, 2022
    #1
    codestage likes this.

  2. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,629
    I suspect the UnityEngine ones are the C# class and the others are the C++ objects, which could explain the difference in size (most data is stored in the C++ types).
     
    Neto_Kokku, Mar 15, 2022
    #2
    MartinTilo likes this.

  3. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,104
    Yup. A C# Transform has 3 fields, all inherited from Object. Assuming a 32 bit system, 50771 * 3 * 4 bytes = ~1.2 mb, so that's very sensible.

    The 26 mb for the 70k c++ transforms seems insane, though - that's almost 100 floats worth of memory for each transform! I assumed it only needed a matrix4x4 and a parent pointer of some sort. It could be that it's the size reserved for transform data?
     
    Baste, Mar 15, 2022
    #3

  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,968
    Hello,
    It's been sorta answered all ready but yes: That's the Native "Unity" Object (no name space, basically everything that on the Managed Side would inherit from UnityEngine.Object) and the Managed Shell Object (also referred to as Managed Wrapper or when leaked while the native Object is Destroyed: Leaked Empty Shell or Fake Null).

    Also, Yes there is a GameObject Type object and a Transform component. The Scene Hierarchy is technically structured by Transforms, not by GameObjects. The Size of the GameObject Type is mostly informed by Serialization data and not by the components, which are all listed out on their own in the Memory Profiler UI (albeit referenced by the the GameObject.

    Yes we know this is confusing but the package so far has just been showing you the data the way the data is structured. While that is technically correct, it is not necessarily in a way that is intuitive to a Unity User that hasn't gone deep on the Native backend and how our bindings / Managed Shell <-> Native Object <-> Native Root <-> Native Allocation mapping is working.

    We are slowly adding extra processing to the data and are restructuring the UI to something clearer and more intuitive. The Details Side panel has already started that transition. It shows clearly if an Object is Native, Managed or if we have combined the Native Object with the Managed Shell to show a richer version of that object. We want to similarly merge GameObjects with their components, and allow to e.g. sort them by the SceneHierarchy so that the data looks a bit more sensible and is more intuitive to grasp.

    The old tables and the TreeMap are not getting that treatment though. They are now very much put out to pasture and all focus is on replacing them with better UI TK tables in the versions to come :)

    The more complex the transform Hierarchy, the more memory they need to store. I.e. Transforms store a list to all children.
     
    MartinTilo, Mar 15, 2022
    #4
    d11tzechianteoh, Baste and TJHeuvel-net like this.

  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,968
    Oh yeah and: you only need a Managed Wrapper to a native object, if something from C# wants to access it. On first access the Shell is created and retained. This is why you are seeing less Managed Shells than Native Objects, because some of them are just not needed (so far) for your C# Code
     
    MartinTilo, Mar 15, 2022
    #5
    TJHeuvel-net likes this.

  6. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    787
    I cant show you with screenshots, but its really helpful to open them up. We have one object thats basically the root of the scene, and this takes up 50% of the transform size. This is only the m_children property being huge, the profiler makes this very obvious.
     
    TJHeuvel-net, Mar 15, 2022
    #6
    MartinTilo and Baste like this.

  7. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,968
    Yeah, those root level transforms are terrible for performance.
    1. They take up a lot of memory
    2. They make it impossible for separate branches of the scene hierarchy to be updated independently from each other.
    So I'm glad the memory Profiler is helping in pointing them out.
     
    MartinTilo, Mar 15, 2022
    #7

  8. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,104
    If somebody would go nag whatever team's supposed to be working on hierarchy folders to get on with it, we wouldn't keep using root level transforms.

    Before nested prefabs, we had workflows where generally every single level had a single root object that everything was required to be under, for organizational purposes.
     
    Baste, Mar 15, 2022
    #8

  9. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,968
    I hear you, believe me.

    Just stating how it is for the time being. :/
     
    MartinTilo, Mar 15, 2022
    #9