Force Editor to release memory?

I have an editor tool which is importing external heightmap files and creating terrains from them. Part of the tool is importing tile sets, which could be of extremely large sizes. Unity obviously has memory limitations, which I thought I got around by adding the ability to convert the generated terrains to prefabs, and then removing the terrains used to generate those prefabs from the scene.

I use GameObject.DestroyImmediate to destroy the terrains once they are converted to a prefab asset, and try to force memory freeing by calling EditorUtility.UnloadUnusedAssetsImmediate and GC.Collect.

However, memory continues to increase and if enough tiles are imported, the editor will crash.

It seems to me that although I am destroying the terrain game objects, somehow the scene is still referencing them. This seems likely as I have tested destroying the prefab assets themselves after they are created, and when I try to save the active scene where the terrain game objects were created/destroyed, I get this error:

Code (CSharp):

1. Component could not be loaded when loading game object. Cleaning up!
2. UnityEditor.SceneManagement.EditorSceneManager:SaveScene(Scene)
3. TerrainImporter.TerrainImporter:RemoveDuplicateTerrainInScene() (at E:/Backup/GithubRepositories/Terrain-Importer-Library/TerrainImporter/TerrainImporter.cs:866)
4. TerrainImporter.TileSetImporter:Import() (at E:/Backup/GithubRepositories/Terrain-Importer-Library/TerrainImporter/TileSetImporter.cs:126)
5. TerrainImporter.Importer:InitializeImport() (at E:/Backup/GithubRepositories/Terrain-Importer-Library/TerrainImporter/Importer.cs:51)
6. TerrainImporter.TerrainImporterObjectEditor:InitializeImport() (at E:/Backup/GithubRepositories/Terrain-Importer-Library/TerrainImporter/TerrainImporterObjectEditor.cs:50)
7. UnityEditor.EditorApplication:Internal_CallDelayFunctions()

Looking at the profiler, I see ManagedHeap.UsedSize growing, so clearly something from the heap is not being freed.

I'm not sure what I am doing wrong. I feel that the two methods I call to free memory should be enough, so long as there are no references to the terrain, which there are not. Is there another method I should be calling? Has anyone got such a tool working correctly, where you are generating prefabs via an editor tool?

 

I also tried this sequence of method calls and it doesn't help.

Code (CSharp):

1. AssetDatabase.SaveAssets();
2. GC.Collect();
3. EditorUtility.UnloadUnusedAssetsImmediate();
4. AssetDatabase.Refresh();

Sometimes ManagedHeap.ReservedUnusedSize increases and UsedSize increases but not as much.

 

Some more info, here is the Simple Profile Analysis before and after my editor tool runs (here it is importing for heightmaps and creating four terrain prefabs.

Before:


After


Of note, Textures and Total Objects in Scene go up by 17 and 3 respectively, however Textures memory remains at 5MB. Assets decreases from 1584 to 1544 which I don't understand.

 

Other things I have tried:

Deleting temporary textures that are assigned to the terrain alphamap using DestroyImmediate(obj, true) instead of AssetDatabase.DeleteAsset.

calling Resources.UnloadAsset(terrain.terrainData) before destroying the terrain in the scene. I also tried calling this on the terrianData of the terrain prefab.

setting terrain.hideFlags = HideFlags.HideAndDontSave;

Please, I have seen several threads about this issue and they all remain unsolved. Is there no Unity technician that can comment on this issue?

 

I downloaded the Memory Profiler package but I guess I'm not using it right, because when I take the difference between a pre-tool use snapshot and post-tool use snapshot, it doesn't show the memory increasing much.



5039 new items in the post-tool use snapshot, but the Owned Size of these new items is only 368.4KB and Native Size only 2.3 MB.

Yet the task manager shows the editor increasing by nearly 800MB.

 

It looks like I have figured out what is going on. I allocate what I thought to be temporary arrays in different places of the tool. These arrays are enclosed in local methods so their memory should be theoretically freed once the local method is done executing and the garbage collector runs.

For whatever reason, they are not freed however. I don't know if this is some weird gotcha because the tool is effectively run in a single editor frame, or if the garbage collector is just not able to run in the editor. Even if I run the tool and then try to force the garbage collector to run via a separate command, well beyond the frame that the tool was run in, the memory is not freed.

I have tried to reduce new allocations by reusing arrays, however there are some spots where this is just not possible. For instance, I am using Texture2D.GetPixels32 and Texture2D.EncodeToPNG, both of which allocate new arrays.

Has anyone run into these issues before? Is there a way to force the garbage collector to collect these arrays?

 

Unfortunately I do not find any of the arrays in the memory profiler, however I am new to the package and may be missing something.

All of my code is contained in an external c# library that I use via a DLL, so perhaps that is the reason nothing shows up in the memory profiler.

The latter, my code is complicated but you can think of it like this:

Code (CSharp):

1. public class CustomInspector : Editor
2. {
3.     void OnInspectorGUI()
4.     {
5.         if(GUILayout.Button("Create Terrain"))
6.         {
7.             EditorTool tool = new EditorTool();
8.             tool.CreateTerrainFromFiles();
9.             FreeMemory();
10.         }
11.     }
12. }

Where all of the array allocations, and everything else for that matter, happens inside that base CreateTerrainFromFiles method. There are no outside references to the EditorTool class, so it should be destroyed immediately after the OnInspectorGUI is run. Yet if I try to call UnloadUnusedAssetsImmediate or GC.Collect manually many "editor frames" after, the memory created in the editor tool is not released.

This makes sense and explains why memory doesn't ever go down, however I still don't understand why it keeps growing. Unity not releasing the pool memory is not an issue it seems. Within these pools, if I create an array, but then no longer have a use for this array, I should be able to set the array to null and tell Unity to "reclaim" the array so that the next new array call uses that same memory.This does not seems to be happening however. Unity just keeps increasing the pool size every time I create a new array (and likely anytime I create any new reference type or object that needs to be allocated on the heap).

Why is that? Is it because the editor code is all executed in a single "editor frame"? Or should things work how I just stated, and there is some error in my code that makes Unity think the allocated memory belongs to my arrays and cannot be reused?

Put another way, I feel like it should work like this:

Code (CSharp):

1. Stuff s1 = new Stuff();
2. Stuff s2 = new Stuff();
3. Stuff s3 = new Stuff();
4. UseStuff(s1, s2, s3);
5. s1 = null;
6. s2 = null;
7. s3 = null;
8. UnityCollectNullStuff();
9. Stuff s4 = new Stuff();
10. Stuff s5 = new Stuff();
11. Stuff s6 = new Stuff();
12. UseStuff(s4, s5, s6);
13. //etc.

In this example, Unity might allocate new memory for the first three "new Stuff" calls, but the second set of calls shouldn't. The memory from the first three calls should be used.

However, either I am not calling the right methods to notify Unity to mark the memory as "open for reuse", or Unity is unable to reuse that memory, which seems odd.

I tried this, but for the reason stated above (code is in a DLL), I believe the memory is not showing up in the profiler.

 

@MartinTilo

I have simplified the main issue I was talking about in the previous post into a simple editor test:

Code (CSharp):

1. using UnityEditor;
2. using System;
3.  
4. public static class EditorFreeMemoryTest
5. {
6.     [MenuItem("Assets/Test Memory")]
7.     static void MemoryTest()
8.     {
9.         for (int i = 0; i < 10; i++)
10.         {
11.             CreateMemory();
12.             FreeThatMemory();
13.         }
14.     }
15.  
16.     static void CreateMemory()
17.     {
18.         int[,] stuff = new int[10000, 10000];
19.         stuff = null;
20.     }
21.  
22.     static void FreeThatMemory()
23.     {
24.         EditorUtility.UnloadUnusedAssetsImmediate();
25.         GC.Collect();
26.     }
27. }

Each call to CreateMemory creates roughly 400MB of data. Ideally, the 400MB would be created once and then reused by each new array, but it is not. Instead, 4000MB of new memory is allocated by Unity.

Is there any way to get Unity to reuse the memory? I'm going to keep testing stuff to see if I can come up with something, but in the mean time if you have any ideas please let me know!

Thanks so much for the assistance, it is greatly appreciated!

 

I am a little confused; you say I should study this in a "build player" however I am specifically concerned with the behavior in the editor as this is editor only code; I am not sure how testing this all in the player would be beneficial given that.

In any case, I created a static field to hold the array reference, then in my CreateMemory method just allocated a new int[10000, 10000] array.

FreeMemory doesn't seem to do anything, I see no difference in Task Manager calling this method even with GC.WaitForPendingFinalizers added, however I still took some snapshots after calling this method.

What I found was, the memory profiler shows the previous array memory being deleted after the first CreateMemory call:



However, this memory is not returned to the OS, Task Manager just keeps growing and growing in size even if FreeMemory is called manually.

PreCreateMemory1


PostCreateMemory1


As you can see the array shows up and is roughly the size I would expect it to be (~400MB). The memory address is 1510014976.

The Memory Map also shows up as this:


I am guessing this bright blue region is the array.

PostFreeMemory1

The array is gone, which seems to be correct, however Task Manager does not show this memory being reclaimed.
The deleted array does show up in the diff, and the bright blue region in the Memory Map turns dark blue (whatever that means).

When I call CreateMemory again I get a Memory Map with the Dark Blue region seen in PostFreeMemory1 snapshot, plus a new bright blue region which I presume is the new array:



PostCreateMemory2
The bright blue region turns dark blue.

The first question is, what does a dark blue region mean? It's seems like it is a block of memory that is freed/available for reuse, which makes it seems like my FreeMemory method is actually doing something. But if that is the case, why is Unity allocating a new chunk instead of reusing this memory? I am going to upload the snapshots in the next post, thanks for all the help!

 

Nevermind, they were too large. you can download them from my dropbox account if you are interested, although the descirption/images posted above will probably be enough for you to see what is going on here.

Dropbox Link to Snapshots

 

While I understand the reasoning behind this (so users can have equivalent performance in editor vs player [for the most part], I do wish there was some special consideration for editor only memory allocations, i.e., allocations made outside of Play Mode within the editor. I mean, there are just different use cases between these types of allocations and allocations within a game, so it doesn't make sense to treat them the same. I guess this is GC related and not Unity related though?

Okay, I get what you're saying, but yeah, I think I need to keep testing in the editor as this isn't typical code that will eventually be run in a build, it is editor stuff only and if there's an issue with how things are working in the editor than it is pertinent to my problem.

Okay, that's what I figured.

When I click on the regions I don't see any additional information. I don't see any new version to update to, I am using 0.2.3 preview 2 (I am using Unity 2018.4, that might be why there is no other version available).

While I do understand this, if I run a test where memory is created and freed in successive iterations of a for loop, then nothing else should be able to allocate new memory in between the array creation/freeing steps, right? Take this code, for instance:

Code (CSharp):

1. static void MemoryTest()
2. {
3.     for (int i = 0; i < 10; i++)
4.     {
5.         CreateMemory();
6.         FreeThatMemory();
7.     }
8. }

How can something else be allocated in between those calls? Just to take a double look at this, I did a snapshot before running this code and after. Here is what the post-code snapshot Memory Map looks like:

This memory map shows the second chunk having a single array at the end, a third chunk with only an array, and a fourth chunk with 6 arrays. I'm not sure if the other two arrays are somewhere in the gray areas or were created with reused memory.

I'm not sure if I fully understand all the info you've put out there, but I believe this shows the issue isn't with a new chunk being allocated and causing the old chunk to be ignored, as all of the final arrays are part of the same chunk. Therefore, the code should at least be able to reuse these last 6 arrays that are part of the same chunk, right?

There may be a few spots where I can use Native Arrays, but one of the main things I am doing is applying heightmap/alphamap/other terrain data to Unity Terrains. The methods of the Terrian and TerrainData class do not take Native Arrays as far as I can tell, so even if I used them I think I would need to allocate a managed array eventually.

I am also using Texture2D.GetPixels32 and EncodeToPNG, both of which allocate new managed arrays. If you have a workaround for those two methods that would be fantastic, but I don't think there is one.

Thanks again for all the help. You are clearing up a lot of stuff even though it is looking like there won't be a way to get around the problem. I guess I just need to reuse my memory, although I think I will still see the memory grow due to methods where arrays cannot be reused, such as GetPixels32 and EncodeToPNG. It's too bad these methods do not allow a List as input.

 

Strangely enough, through chance I have found that in my editor tool, calling AssetDatabase.SaveAssets() is the only thing that is needed to keep the memory leak from happening. Not sure why, but GC.Collect and UnloadUnusedAssetsImmediate are not even needed.

In the Test Memory code I posted this is not the case, but hey, it works for my editor tool so that is the main issue solved at least.

 

I had a thought that because I am writing new assets to the project in my editor tool, Unity keeps those assets in memory until SaveAssets is called. But I'm obviously not sure if that is actually the case.

You are right about the saving assets the user might not want saved, but as this is the only method I will have to just accept that and put up a warning that SaveAssets will be called when using the tool and tell the user exactly what that means.

 

I am having this problem, except over time, Unity stops hogging so much memory. For example 15 minutes ago, it was hogging about 12 Gb, now it is down to 6 Gb, and I think it might be Windows telling Unity to give up some memory for other tasks? In those 15 minutes Ive run my browser to open about 10 tabs and lots of surfing around looking for answers.

Ive been doing some gnarly run-time texture swapping/remapping on 2048s, and am pretty sure that is what is causing the memory allocation growth, because it was not happening before this. (as in,it used to eat up to 3Gb, and I thought it was bad then... )

EDIT: 5 minutes later, it dropped back down to normal 700Mb, and my computer is running normal again. So, what is telling Unity to do this?

 

Since you are working with runtime code, have you tried using GC.Collect?

 

No. This is actually the first of my research into the whole problem, so I am still debating whether I care. Also I am kind of in transition/prototype phase, as eventually, these shaders will be driven mostly by actual created PNGs. I have read a lot about garbage collection, and mostly just done my best to mitigate it before it becomes a problem.

I just find it odd and I don't see an explanation for this behavior in everything I read here in this thread, so my curiosity has been piqued. I have noticed this before, both the memory spike and the cool-down over time.

I am also experiencing a different kind of "memory leak" where it takes longer and longer to load up the game screen every time, until it is 11 - 15 seconds. I am now stopping and rebooting after about 10 seconds of delay per iteration, thsi is about once every 3 hours of continuous iteration/experimentation

Both of these I find minor inconveniences at the moment, but I am concerned it may make the shaders I am developing unmanageable.

 

So this little thing has popped up a couple times today. Most of the time, Unity doing fine. I would check periodically, and it would be running normal. I can't remember the first time, but the second time, was right after I copied and pasted a shader graph, renamed it, and then applied the new shader graph to a material.

There is no "baking shader"or "collecting shader" or any shader work messages, but I now strongly think it is related to shader graph

EDIT: It happened once yesterday, but no shadergraph work had been done for over an hour. It was a bunch of UI restructuring this time.

It is a minor annoyance right now, as it grinds everything to a halt, and takes about 5 minutes to save and shut down (as opposed to five seconds) to restart. But it is starting to make me wary of shader graph work, which I have noticed has slowed down my experiments.

However, as I have mentioned, if I just let it go, or do something else on my computer, over 15 - 20 minutes, it bounces back to normal.

 

so how do you guys force editor to release memory? GC.Collect, resource.Clean/unload (or whatever it was) and other methods dont do anything for me.

In my case its meshes (im 90% certain). if your meshes are loaded to memory from first to last frame then (MAYBE) unity wont increase memory with these meshes, but for anything like loading the meshes from disk, from resources, from addressables, from internet, or generating them in runtime, i am most certain editor will not clean these for you when you click stop play, and then it will load them again in runtime, adding to the memory

ofc it can be textures and other things too but in my case its meshes im sure as they take most size and i have lot of them (auto generated ones, or loaded to memory during runtime)

so is there any way? reseting unity every a while is kinda annoying

 

I'm not sure about in game resources, this thread was focused on resources loaded outside of Play Mode, for instance with an editor tool. I would have thought any resources loaded in Play mode would be unloaded when you exit Play mode. Which exact method are you using to load the meshes?

 

In my case, I am positive it is this:
https://forum.unity.com/threads/animator-window-causes-some-kind-of-memory-leak-2021-1-5f1.1137055/

It is from having the animator window open for a long time.

 

Anyone who has written an editor script that frees up memory reliably?

I have a procedural generation which (undesirably) uses a ton of system memory, which I am trying to debug. If I had an editor script to free up memory in between plays it would help my workflow a great deal.