I hate to be that guy on HN but this article set me off as a Unity VR developer. I understand this is an introduction for people coming from a web development or other more traditional software engineering background, and the code is purely demonstrative, but it's full of Unity performance anti-patterns. Specifically...
1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensive and will generate a ton of garbage.
2) Constantly Instantiating and Destroying GameObjects during runtime. This will create a ton of garbage on top of the expense of the Instantiate. The solution to this should be an object pool (http://catlikecoding.com/unity/tutorials/object-pools/
). Realistically this is probably outside of the scope of this blog post, but maybe the author should have avoided Instantiate in an introductory example.
3) GameObject.Find to locate a fixed game object in the scene. This should be replaced with an object reference (references can be connected in the editor), or if that doesn't work for whatever reason use Find once in Start or Awake and store a reference to the object are a member variable. Unity recommends to not use it every frame in it's documentation (https://docs.unity3d.com/ScriptReference/GameObject.Find.htm...)
4) Debug.Log can be useful in a pinch, but doing it in Update or other frequently called method can cause performance problems, also printf debugging has never been great. Visual Studio debugger support is really good in Unity, use that.
This code is ok if you don't care at all about performance, but in a VR or AR app you can quickly add milliseconds frame time and make yourself sick writing relatively simple code in this style.
> "This code is ok if you don't care at all about performance, but in a VR or AR app you can quickly add milliseconds frame time and make yourself sick writing relatively simple code in this style."
---
This point needs to be made more often. It's fine to neglect performance when you're writing a CRUD web app, or a non-critical mobile app - the worst that will happen is the user will get annoyed. But in a VR environment dropping frames can make people physically sick.
Yup, agreed on all points! You've hit the nail on the head about article scope. We do mobile VR and these are all definitely no-no's at the end of the day. Discussions on perf will come later. Thanks for pointing these out though!
Are these issues easily fixed by refactoring?
As a newcomer to Unity, I'm ok writing poorly performing quick code to experiment, and properly implement the code at a later stage. I'm afraid that I may burn out too quickly if my first interaction with a platform is too much concerned with patterns.
They are easily fixed with a refactor, but many of the solutions are either easier to implement or not much more difficult to implement than the example code.
Can be fixed with a refactor, but it's best to not get sucked into these bad habits at all. If you are learning, might as well learn how to do things the right way from the beginning.
Hooking up references to GameObjects and Components through the editor is some of the Unity "magic sauce." You should be doing things that way, or by hooking things up once during Awake/Start.
You should also check out the talks from Ian Dundore, he one of the Developer Relations Engineers from Unity. Here is one of his talks from Unite 2016:
If you can read Simplified Chinese, there is a Unity optimization consulting start-up founded by former Unity China engineers called UWA, there are lots of articles on their blog:
Doing Unity optimization is hard. There are lots of gotchas and pitfalls to avoid. Unity is extremely sensitive to memory allocation because its Mono runtime is very old. It runs Boehm garbage collector which is non-generational and non-compacting. It's almost certain that there would be a frame drop when GC happens.
1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensive and will generate a ton of garbage.
2) Constantly Instantiating and Destroying GameObjects during runtime. This will create a ton of garbage on top of the expense of the Instantiate. The solution to this should be an object pool (http://catlikecoding.com/unity/tutorials/object-pools/ ). Realistically this is probably outside of the scope of this blog post, but maybe the author should have avoided Instantiate in an introductory example.
3) GameObject.Find to locate a fixed game object in the scene. This should be replaced with an object reference (references can be connected in the editor), or if that doesn't work for whatever reason use Find once in Start or Awake and store a reference to the object are a member variable. Unity recommends to not use it every frame in it's documentation (https://docs.unity3d.com/ScriptReference/GameObject.Find.htm...)
4) Debug.Log can be useful in a pinch, but doing it in Update or other frequently called method can cause performance problems, also printf debugging has never been great. Visual Studio debugger support is really good in Unity, use that.
This code is ok if you don't care at all about performance, but in a VR or AR app you can quickly add milliseconds frame time and make yourself sick writing relatively simple code in this style.