Recently I’ve noticed that compiling and launching of my project inside Unity editor takes much more time than couple days ago. Much more. About 30 seconds just for launch instead of 2 seconds. I’ve examined previous versions of the project and found that this delay appears from nowhere because of small changes in scripts. Nothing else have changed. And nothing special in this lines. Just game logic. And I also see in task manager that in “good” version game takes 100 Mb of RAM when launching. In “bad” version it takes 1Gb (!) (and falls down to “good” 100 Mb when launched). Just because of 30-40 more lines of code in game logic…
I’ve tried complete reimport of assets. Nothing happened.
I’ve examined more and the result is in attach. The reason is that than I have two classes and both have a reference to each other in their variables. Unity begins to lose memory and lags.
To test:
Place scripts in an empty project
Add component AttachIt to camera.
Uncomment more ‘var bigger_’ in SmallerClass
Is there any trick to fix it before major bug fixes in Unity?
Is such bug reported already?
PS: By the way in my project (not attached to this post but where I’ve found this bug) there are also a problem with viewing such variables like AttachIt.big in inspector (with infinite cross reference big->small->big->small). When I select object with such variable in inspector while playing Unity silently crashes.
Couple of days ago I started to port my project to the iPhone and it often suddenly crashes (in general I couldn’t launch it while it works on pure Mac).
I’ve found that this bug totally crashes Unity iPhone 1.7. More over in PC/Mac there could be one or two cross referenced class variables and problems start with three or more of them. In Unity iPhone it’s unable to have even one.
Experts, please, say something about it!
Will it be fixed in Unity 3, or I should start rewriting code?
No two classes should reference each other.
Absolutely do your best to make only one reference the other, because otherwise you’re going to have these kinds of issues.
crashes on the iphone can just as well be cause you run out of memory or take too long to launch and get killed by iOS (you have max 20s of unresponsiveness, after that the app gets killed forcefully)
Thank you! Think I will
For the possible future solutions. Is it documented requirement or may be some issue of “Mono”?
And how it is done that GameObject has transform variable and Transform have gameObject variable?
This is a result of how the Unity inspector works. For every public variable that is serializable (and all your classes are, when using JS) Unity will create an instance for you to edit in the inspector. Of course, when such this instance has any (serializable) references itself, it will also create those, or you wouldn’t be able to edit them. Unfortunately, this means that whenever one of your classes somewhere down the line, contains a reference to its own class, the inspector ends up in an infinite loop creating new instances. This completely freezes the editor. Unity 3 seems to have “fixed” this error by terminating this serialization after a certain time, which means it will no longer crash but becomes very slow instead.
If you only use these classes at runtime and do not care about their data being stored or editable in the inspector, simply make the monobehaviour variable private.
If that’s not an option, the only way around it, is not to have recursive references in any of your non-monobehaviour classes. Sadly this makes persistently storing recursive data-structures inside a monobehaviour very difficult. You can possibly use ScriptableObject to work around this, but it would require writing your own editor scripts to be able to edit the data in the inspector.
Thank you for the reply.
In this case it can’t be because of such things. The example project is absolutely clear. And the crash happens in the editor, without any connection to iOS.
“Private” solution works but not in Unity iPhone. It starts to compile such code and still crashes at launch. I’ve just checked this.
The only way is to address such variables through indexes in arrays. But it seems to be slow and cost time of development to trace all variants…
And I’ve just checked C# script for such thing. And it’s OK there.
