- A* version: 5.3.4
- Unity version: 6000.0.23f1
I’ve been tracking down an issue that I’ve isolated to the DrawingManager. We have a project where we build our addressables from the command line. During those builds, I noticed that the GarbageCollectSharedAssets (which runs on each scene load/unload) was taking a lot of time. Further, I noticed that we had a really massive amount of Unity.Object alive at the time (more than 1 million). MarkObjects was taking almost all of the GC time, going frequently above 4 seconds per GC (which makes sense, MarkObjects would scale with the amount of data to analyze).
After further analysis, I’ve pinpointed that this issue is coming from the DrawingManager. In batch mode, any IDrawGizmos still gets registered with the DrawingManager. However, since there is no rendering being done, the static list that holds all IDrawGizmos never gets checked to clear values. This causes DrawingManager to retain every single IDrawGizmos MonoBehaviour that we load during the lifetime of the build, and everything that they reference (i.e. the whole scene!).
I’ve tested a potential fix where I
- store the status of Application.isBatchMode in DrawingManager.Init() (because we can’t check it inside a MonoBehaviour constructor)
- When DrawingManager.Register() gets called, we force return if we’re in batch mode
Using that fix, I’ve noticed that the issue is fixed with this. GC times go down and Unity.Object reports only less than 20k instances when cleaning instead of a million. This also improves our build times significantly; starting from an entirely fresh working copy with no Library folder, we go from about 54 minutes without the fix to about 46 minutes with the fix.
