Unity.Object takes up 16 MB, only 1 reference

So recently I've been using the Memory Profiler to get a better understanding of our games memory. Occasionally I run into a handful of Monoscripts (8 or so) that have a native size of 16 MB. When I look at their references they usually only hold 1 reference. I've looked through the scripts and there is nothing that stands out to me to cause it to be so large. Also not every script is this size, and not every time the same object is this large. Does anyone have any hints as to why some scripts would be exactly 16 MB some times?

Hi there,

Do you have any further details on this? E.g. screenshots of such objects in the memory Profiler, code snippets or similar? Is this tied to specific types? Are these ScriptableObjects?

Hello Martin,
So I do have some screenshots, but I can't really provide code at this time as it's under NDA and I would need permission from the owners.
First is a screenshot of a couple of the various objects that are doing this.

Next is a break down of the screenIcon object, then an image of the 1 reference to it. Lastly a breakdown of the arrow object as well. I do suspect that it may be due to one of our scripts, but it's hard to tell as not every object that uses that script is taking anywhere near 16 MB, and in some cases the connection from one object to that script would be through a maze of references. I wasn't sure if there was any other info I could gleam from these profiles to tell me what is taking up the 16 MB.

6484423--728674--Screenshot 2020-11-02 175952.jpg
6484423--728677--Screenshot 2020-11-02 180016.jpg
6484423--728680--Screenshot 2020-11-02 180304.jpg

Do these MonoBehaviors per chance have some amount of serialized data on them? Maybe an arrays or similar?

They are all marked as System.Serializable. Lots of classes that can have references to other classes. 6488942--729404--upload_2020-11-3_23-27-44.png

MonoBehaviors are Serializing their public fields and those marked as [SerializeField] irregardless of whether or not they are marked as Serializable.

If those classes are being referenced in public/SerializeField fields on these MonoBehaviours that are reported as 16MB, it could be that the MonoBehaviour native size is including the data in these serialized fields. I'm not yet certain of this, still gotta check the codebase, but that is what would make sense here.

Does that add up?

Also, is this a snapshot made in the Editor (i.e. Play Mode or Edit Mode) or in a build Player and is there any difference on these between snapshots made in the Editor vs ones made on a Player.

And do these MonoBhaviours reside in particularly long/big .cs files.

These snapshots come from a PS4 build. The classes posted above do have a lot of public fields referencing others. The .cs file is about 1800 lines long with 14 classes in it, but only 1 of them inheriting from a class that inherits from MonoBehaviour. One of the classes in this script also inherits form ScriptableObject. I will check today if these 16 MB MonoBehaviours exist in an Editor snapshot as well.

Well I tried to investigate an editor snapshot, but was foiled by the following errors 6498046--731326--upload_2020-11-6_14-38-16.png

Either way, looking at the Monobehaviour usage of 49.7 MB I don't think that this problem persists in Editor and is just a build issue.

Have you tried having just the MonoBehaviour in its own file and all other classes in one or more separate files?

0.1.0-preview.9 is quite outdated at this point, could you please update your version of the memory Profiler via the package manager and try again?
If this issue persists post updating to the latest package version, please file a bug report.

Also, post updating, please look at the player snapshot with those 16MB MonoBehaviours again, just to be sure that this size wasn't a crawling issue in an older version of the package.

But basically we are currently guessing, based on the rough info we have on your situation and the code we looked at, that the native object memory usage for a MonoBehaviour includes the scripts text file size, also in a build. We'll keep digging a bit deeper as to whether or not that is actually what is happening and if that could be improved/fixed or if something relies on this being the case.

So I updated the memory profiler to 0.2.6 preview 1, I took a snapshot and was still seeing the 16 MB Native memory. I then took all of the classes out of that script that didn't inherit from MonoBehaviour and put them in their own script The size of that script.cs file is 30 KB. We may be able to get a test project going that we could send over, I will have to check with the project owners.

Just to clarify, you took another snapshot after splitting the class up and it was still 16MB? I guess that rules out the script file size as contributing to the memory size. That would have been rather weird anyways but good eliminate. The colleague that was looking into that fell ill so we didn't dig deeper yet, but a confirmation that I understood you correctly here would mean we wouldn have to.

So next up is the more probable scenario, that it is the serialized data.
If you serialize an object of this class (ideally in the same context and of one of these object instances that the memory profiler shows) let's say to JSON or even to a binary stream, how big is that serielized string/stream then?

This seems to be a PS4 only issue so we are going to move to their support forums. Thank you for all the valuable information though! Sorry to get back so late on this.

1 Like