Please show your support if you have ever had any of these issues impede your development or production efforts.
I love Unity, and I will continue to find work arounds for these issues, but some of these are show stoppers and require serious attention from the dev team, lets raise some awareness.
Issue #1. GUI.GC lag spike.
When running your game in the editor, intermittently there will be a 1 or 2 second lag spike. Checking the profiler will reveal that it is an internal GUI call from the editor that is taking up 90% percent of the process during that spike. This is after removing any OnGUI calls from the entire project to make sure it wasn’t on my end.
I have to completely separate games that suffer from this issue in the editor.
Issue #2. Application.LoadLevel() RPC received on a game object which does not contain a script to receive the event.
It is my suspicion that the network view ids from the previous scene are not being released correctly due to a garbage collector mix-up, and are now conflicting within the newly loaded scene.
Please if you are experiencing similar issues reply to this thread.
The lag spikes can be gotten under control by a coroutine that cleans all generates since the last clean. I’ve commonly such code present on anything where I know that it will generete trash (heavy string usage for example), doing so at a reasonable rate. On the iOS I for example see it as crucial as a GC run there is deadly (2+ second freeze all XX seconds)
System.GC is at your help here.
2 is not needfully related to mixup, it has always existed.
The normal way to approach it is to use the levelprefixes to cut off “old dead views”.
I’m trying to test this out, I’m new to managing the GarbageCollector in any real way, but I’m wondering if you have a sample for this.
I’m trying to use GC.Collect(0), but I still end up with a giant spike, as well it seem that Unity is not supporting Object Aging (MaxGenerations always returns 0 for me in Editor).
Is there something I’m missing or some way to enable the ability to use this.
What hardware do you have?
Just to ensure that the spikes are not a problem from you trying to do 3d dev on a 2GB RAM Vista / Win7 machine which you can forget right from the start for example or something similar (cause then its caused by enforced massive collects and / or paging / virtual memory)
It’s on an iMac, the Spikes are completely invisible on it performance wise, I only spot them in the profiler. But the real issue is I want to implement it for iPhone, and I’m thinking if the iMac doesn’t support generations, how in hell is the iOS going to do it? And if it doesn’t support generations calling collect via coroutine really isn’t any better because you can’t optimize it to only collect on the recent things.
Ah well the spikes in the profiler are normal, thats meant to happen.
The GC under normal working will clean up periodically, be it on editor or anything else.
This also holds for the iOS.
But its especially iOS where I’m using above process to prevent “pilling up till too late”
And yes you can opt it to collect only the recent things as you can store the generation you are up to for example and only collect to back to that generation.
Also if you run it more periodically than unity does, you don’t reach the “wall of terror” ie it won’t pile till the cleanup takes too long as you cleaned the garbage thats older than your last collection already if you collect back to generation 0 (can be too much bruteforce though depending on what you do etc, best you test it and its impact through the on device profiler you can enable in the xcode project generated for iOS deployment)
MSDN is only partially of use in this case as the GC in mono is not comparable to the MS.NET one actually
The editor, especially when you have the profiler open, is in no way representative for anything.
The profiler on its own on weaker systems can take up to 50% of the performance for drawing graphs. so when profiling ensure to have it closed, pause and then look in.
also the spiking is there on any platform and always (as it runs at discrete points in time, not continous) but it should not be a problem. if it is one you should stop generating this large amount of garbage, though the question is how you generate them then (heavy string operation usage or generating dummy transforms etc … no idea, there are two dozen ways to trash flood the GC easily and several thousands that do it with a bit more effort ;))
This is an issue without the profiler active/running . This is why I believe it is internal to the editor: Once we notice the issue, we then bring up the profiler, which points to GUI.GC hogging the process. We have removed absolutely every OnGUI from our scripts. We have nothing we can think of that is flooding the GC. The only GUI calls that remain are those of the editor, please reference the link from my first post which proves this.
Don’t touch OnGUI as it has been since day 1 of Unity iPhone.
Use something thats really mesh based and uses the touches, cause OnGUI isn’t multitouch capable even by Unity 3.1 so still only of use for main menu.
And when working with it on iphone: don’t forget to disable the usage of layout in the monobehaviours awake, cause thats one of the major reasons for the overhead, without layout many of the calls to ongui are gone.
The company I work for have noticed the lag spikes also on several machines. We had to stop using OnGUI completely (this is for a web player and windows stand alone build). We wasted so much time debugging that GC issue around the GUI :(.