I am storing over 100 Million Floats/Ints between several arrays as an editor script as serializedfields. This causes the RAM to keep piling up. If it doesn’t crash, I can exit Unity, come back in and memory is back to normal. What can I do to maintain the RAM while the code is running? I have 16GB of RAM by the way.
Why?
I’m not clear what mean by ‘as serializedfields’…
This I’m not sure by. 100 million floats or ints is about 400 million bytes. 400 million bytes is really only 380 megabytes.
Which is a lot, but it’s not piling up.
This says to me that you’re generating new arrays over time. So you’re taking up 380 MB each time you do. Is this happening?
You should consider reusing the arrays. Though again, I’m not sure what “as serializefields” means, and what implications that has on recycling the same arrays.
I am storing for foliage placement. The serializedField is so that the variable gets serialized. In this editor script, I initialize several serialized arrays, then assign the elements throughout the script. It is strange, the memory seems ok until the script completes, and then as the editor trys to get back it itself it keeps upping the RAM. I’ve added EditorUtility.UnloadUnusedAssetsImmediate() and System.CG.Collect() after some solid portions are complete. But as I said really the problem seems to be when the script has finished.
I wonder if the editor is trying to create a massive undo list for the serialized variables
EDIT: I tried Undo.FlushUndoRecordObjects at the end of the script. No luck.
Tested a lighter array amount and it still stacks up RAM after script completes, and it hangs and that amount indefinitely until the editor is closed and reopened. The stacked amount of RAM is smaller with smaller arrays sizes but it still shouldnt be doing that. It prevents large scale editor script operations. The editor must be doing something after the editor script is complete and not letting go of it…
I think it has something to do with the way Unity serializes. It must be waiting until the end to finalize serialization. But even then I wouldn’t think that RAM should keep hanging around after.
WooHoo I figured it out. I was (maybe unconventionally) using a public bool to start my editor script. So I think because of the bool getting a serialized undo, it was making a huge mess at the end when the script finished. So by calling Undo.FlushUndoRecordObjects at the very beginning of the script, I eliminate the bool reference that started the script, and therefore, everything the editor script does from there, becomes unrelated. SO happy I figured this out. Very weird to me, hopefully this helps someone.