Question Monobehaviour with huge native memory usage

Hey!

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.



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/

 

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

 

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

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)