Memory Profiler: How to make sense of skinned mesh data?

Hi,
Just going by the screenshot, the way I read this you have the Cat prefab resource, from which you instantiated and the one you instantiated. On the top-level of this prefabs hierarchy, you can tell which one is which by the Native Object Name: Cat_Prefab and Cat_Prefab_Instantiated. The GameObjects underneath that top level object don't get their names changed on instantiation. You can still tell them apart by looking at the sign of their instance IDs:

• positive means they where assigned an instance ID on loading it from file and remapping file ID to instance ID. This means your Prefabs, Assets and in-Scene-objects will get positive numbers.
• Negative means that the instance was created in memory, e.g. through instantiating it.
• Note: It can still happen that a negative instance ID might relate to an object which is related to a file, if the object is created before the association is made. In this case the instance ID would be negative but isPersistent would be true.

The Prefabs consist of different GameObjects with different components on them, each listed separately and those that you keep a reference to in your scripts have managed objects that reference the native ones so that you can access them via script.

That endless list is just a very awkward way to list out circular references. In this case this circular reference exists because of the special relationship between GameObjects and their components: the GO has a list of all its components and the components a reference to the GO. The circular nature of these references doesn't really matter because unless you go and destroy specific components, they will live or die based on the GO anyways.

 

We'll clear this up with an exhaustive explanation for how Memory works in Unity as part of a Manual page I'm writing on (part of my message above will be used in the draft now) and by providing clearer and cleaner paths to roots in the Memory Profiler package UI.

 

Oh yeah and, that name is coming from the GOs name field so each component on the same GO has the same name associated with it. For assets it would be the file name

 

All awkward leftovers that we need to clean up when redoing the table views. Native size only gets listed on managed shells because it's supposed to highlight that there is more to it than the size the shell owns. Native ones own their entire memory which is fully native, so nothing to call our specifically. When looking at the All Objects table as in this example, they should probably get stitched together, but instead it just lumps the two tables together... We'll get to that.