Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.

    Read our full announcement for more information and let us know if you have any questions.

Question Monobehaviour with huge native memory usage

Discussion in 'Profiler Previews' started by Hik-AV, Jan 30, 2023.

  1. Hik-AV


    Mar 24, 2021

    I stumbled at something that I'm having some trouble reading and pinpointing the issue. One of our MonoBehaviours is indicating a huge (10MB) native memory usage which really differs from all our other MonoBehaviours and anything I've seen. Screenshots bellow displaying the behaviour.

    Screen Shot 2023-01-30 at 19.20.22.png

    What I'm failing to understand is who exactly owns this native memory and whether it really is contributing to the memory footprint of the app.

    The script in the screenshot is a pretty simple MonoBehaviour, it does not cache anything special on memory and does not create resources. It does serializes a link to a ScriptableObject which in turn references other SO's and plain c# classes (some layers deep) that download things and create textures. If those were the culprit, am I correct to assume that this native memory would show up on those SO's entry instead?

    Also, as I said earlier, if there is any native resources that could come from a indirect reference, it would be Textures. If that's the case, is it possible that this native memory is also shown in the Texture type, essentially showing up twice in the tree view?

    Some context: I'm on Unity 2019.4.37 using the memory profiler package version 0.6.0 and the snapshot was taken on an Android player build. Unfortunately I'm unable to share the code (maybe some snippets if necessary). Also, I'm aware that this Unity version is not currently supported so I don't expect much in-depth help, but any insight into this would be really helpful. :)

    Btw, the memory profiler is a super awesome tool and gave me lots of understanding on Unity memory management, thanks for all the folks working on this project! o/

    Attached Files:

    Last edited: Jan 31, 2023
    alexeyzakharov likes this.
  2. alexeyzakharov


    Jul 2, 2014
    This looks strange - the SO reference should not inflate the Area Trigger object and Texture is also a separate object which is tracked elsewhere. The native memory of MonoBehavior object is in the 1KB range and everything above that is usually represented by the data allocated during the deserialization of the object. My hypothesis would be this is a serialization buffer attached to the object. It would be useful to look at the script to see if there are any suspicious fields
    Hik-AV likes this.
  3. Hik-AV


    Mar 24, 2021
    Thanks for the pointers @alexeyzakharov!

    In my first triage I ended up brushing the serialization off as it was all pretty standard, but after your suspicion I took another look at it. Most of the serialized fields were primitives or Unity Object references, but one of them was a serializable data class so that caught my attention.

    This data class had a substantial number of serialized fields and had some SerializationCallback logic, so I tried removing it and voilà - the memory issue was fixed! That said, this class wasn't something so out of ordinary: I'm talking about a total of ~100 serialized fields (considering all the nested fields) with some arrays mixed in there (all empty in this instance) and the callback logic was basically reorganizing some data to be exposed.

    So tbh I still don't exactly understand why this data class was responsible for such huge memory usage.

    Anyway, thanks to your help I could at least tackle the symptom. We didn't really needed the field, it was mistakenly set as public and ended up serialized, so it was a really easy fix and the problem is solved :p

    Thank you again, and if you have any ideas about how a data class can demand this much memory I also would love to know :) (though it is not as critical)
    alexeyzakharov and MartinTilo like this.