Most of my projects in unity run pretty good but for done reason it randomly likes to give me a glitch looking like a lash our hicup while testing in editor mode, and every time I check my profiler it say that the garbage collector out high and on the graphs it shows lik steady peaks after time, then it randomly ruins fine like nothing happened, so far this doesn’t happend on a build but sometimes its hard testing with it, for example in my fps project when the hicup hapens it sways too much and I’m only using a lerp function.
When the GC generates frequent spikes, your program is leaking memory. If you create a lot of new class instances and use it them only for a brief time, eventually the GC will have to clean them up, or your program would run out of memory.
To avoid garbage collector spikes, you will need to eliminate the leaks in your code. Find code that creates classes (normally you can search for the ‘new’ keyword), or arrays (for example GetComponentsInChildren or other Unity functions that return an array create one) and rewrite it to not create as many objects. I often find that the GC is triggered in a function that leaks memory, which sometimes allows you to find the leak quicker.
Note that structs (e.g. Vector3 and Quaternion) are special in that they are created on the stack and are not managed by the GC, so don’t bother trying to fix Vector3 stuff, they are not the problem.
Tom
If you see GC spikes its out of my experience to 90-95% due to one of 3 reasons:
- OnGUI usage without proper event code and event consumption especially
- heavy string usage with embedded strings in code, at worst tag comparision which is a fat no go for ‘general usage’
- Incorrect usage of arrays that get constantly replaced instead of following the “pow2” expand-shrink rules
Other things normally are incapable of really creating spikes out of my experience, not matter how stupid you did them unless you wrote code that on purpose trashes everything.
Don’t forget that many things unity does do not even exist on the .net layer, they only have proxy classes for stuff exclusively existing in the c++ side.
I can understand checking my object goddess and list and such but I have a project that is just movement and only has the whole new vector3 which still makes me wonder
Sometimes the editor will have some hick-ups. Restarting the Editor usually helps. If it remains, then it’s caused by your code.
I find the editor often has hiccups that don’t happen on the end release (even from my crappy PPC mac). So, see if its there on build, which I would doubt very much.
I hope this ever gets better some how, now at the same time I’m afraid of mrssing to much with guis since they do a lot of garbage collections any tips on this issue?
Wait for 3.5 if you can afford, or try to make GUIs in the 3D space (with planes and texture/sprite atlasses)
gui textures work fine. it’s only the OnGUI stuff that you should avoid like the plaque
To be fair, unity’s garbage collector does suck. There’s plenty of better ones than the one in use by unity today. As projects get more complicated we find we are battling the gc, and may as well just be writing in C++ - which negates the benefits of c# for speed of coding.
It really does negate it on iOS. I coded faster in C++ than I did in unity js, purely because half the time I am hunting GC issues. A move to the new GC branch in mono would mean I would not need to obsess so much over unity’s GC in iOS.
That is a lot of time saved, and isn’t kinda what unity is all about?. Rapid development? Well the current GC is slowly but surely holding unity back in the rapid development category.
You wouldn’t notice this if you’re doing a crappy match 3. But when it comes to ambitious projects, large in scope with plenty of content, that is a HELL of a lot of work just to get the GC to perform (or essentially: avoid it).
While some good practises exist for all projects, the code mangling for large projects with GC is just too much. It needs fixing.
Um, no.
GC kicks in when there aren’t any references to a variable any more. It uses reference counting. The GC is supposed to be how we deal with memory. Make something null, and it goes away. This is the entire point of using a GC in the first place. It is meant to make your life easier, not make it harder having to dodge it’s usage on a platform designed around a GC.
It has nothing to do with leaks whatsoever.
Unity GC does suck, i spent months doing things i shouldn’t have to to get a rock steady 60fps with no GC spikes, and now there is a newer version of mono that has faster GC, right now unity is like a racing car with a flat tire, but they wont fix the tire.
it seems almost silly if they dont put the new mono version in soon, all the time spent making things faster can be ruined by a few GC spikes here and there
The only thing that ‘sux’ if you feel like having to call it like that is not being informed and blaming it around.
Unity uses Mono 2.6 and its GC, thats all fine.
The mono 2.10 GC might be faster but it also breaks different things and you will not see it during Unity 3.x for near granted.
The funny thing is Unity 2 used Mono 1.x and that GC was really really slow yet the games ran better and we had far less people blame their errors on the GC.
What this tells at least me is that the users grew even lazier than back then and trash pile their games even worse as back then cause the HW is just faster, while the opposite is what you should do so you can conserve more power (especially on mobiles) …
But that might just be my missinterpretation basing on the noobish problem reports I normally see from people that invested at max 3 minutes on the matter instead of even reading the unity documentation present on the matter of how to write code that does not trash bomb, although it would solve over 60% of all problem cases or never have made them happen.
So to sum it up: stop blaming others for your code being trash, its not going to help your motivation, its not showing any professional attitude and at very last its making your game faster and happen within the deadline. Trash is bad, be it real world physical trash or digital managed trash and the more trash you generate, the more time the collectors need to clean it, be it real world or digital. Its as simple as that.
Spend more time thinking on how to do things instead of blindly hacking together stuff that ‘just works’ when you could have been done in a smart way. There are enough articles and threads on the matter and some of the most successful unity users shared their knowledge and best practices so get yours up to date too and you will be happy.
Or continue to blame it on Unity, .NET and whetever else and get your well deserved frustration.
Because it breaks stuff, plus in the past they’ve had to spend a lot of time dealing with Mono bugs. UT generally seems to save things that break stuff for the major versions, so personally I wouldn’t expect a Mono update until Unity 4.
–Eric
Cause Mono 2.10 is not compatible in its code generation with previous versions and it breaks a lot of things to make the new gc work. its not just the GC that changed, the whole lower layer of mono changed along it breaking the compatibility to a degree as high or higher than the mono 1.x to mono 2.x switch that happened for Unity 3
So yeah as mentioned above, I fully agree with Eric, I definitely don’t see a mono update to 2.10+ before Unity 4, a new ‘project breaking’ version either but by then its guaranteed to happen basically because Unity 4 will not have a chance to find excuses for lack of multithreading anymore with UDK and Cry around and to go there, efficient multithreading, the new GCs are a must, not a can
Well, I may have used the wrong terminology (please provide me with the correct term), but there certainly is a lot you can do to avoid spikes by being smart about your memory allocations. If you avoid creating frequent temporary classes, arrays, etc, you can reduce the amount of work the GC has to do, thereby reducing or completely removing GC spikes. The fact that the GC is supposed to make you forget about these things may make it a bad GC (although I have never heard of a GC that can clean up memory without cost in every single situation), but that doesn’t mean you can’t optimize around these issues. The only thing you can’t optimize is the OnGUI spikes, which means you’ll have to stop using OnGUI if that’s the cause of your spikes.
Is there specific documentation on “how to write code that does not trash bomb” or do you mean the scripting reference guide?
There is or at least use to be a page on the matter in the context of mobile optimization where it becomes a major experience problem very fast.
The two basic rules are: don’t use strings unless there is no alternative (especially inline strings and alike are often forgotten to be ‘instant trash’ which makes any tag comparision in a loop an automatic trash generator), use pooling in any case you can, where you have object creation and destruction and recreation at a frequency hence don’t create game objects to destroy them to just recreate them, thats going to trash flood pretty fast too (less a problem on desktop but basically a fundamental thing on mobiles)
There are several threads on the matter some even dating back to Unity iPhone 1.x where the GC was significantly slower
Just use the 3 Rs, reduce, reuse, recycle.
Use pools and reuse old, unused objects so you don’t need to reallocate.
Also, use Value Types(structs) for manipulations within tight loops.
Edit: Also, as mentionned above, strings, particularly when adding them together are bad. Use Stringbuilder if needed when combining complex strings.
Dreamora the old mono GC is out of date and an antique. It performs quite badly despite being simple to integrate.
You’ve got to stop sucking up to unity. They appreciate constructive criticism too, where it’s important. Having to constantly dodge using GC at all is counter-productive to rapid development. It can be massively improved, and it should.
Why shouldn’t unity push to 2.8? are you in charge of what they’re doing? I want unity to focus on fast executable code, so we are able to much more with it on limited devices… IF they choose to wait for 3.0 then it may be a long time coming.