---
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.
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.
https://unity3d.com/learn/tutorials/topics/best-practices https://docs.unity3d.com/Manual/BestPracticeGuides.html
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:
https://www.youtube.com/watch?v=n-oZa4Fb12U
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:
https://blog.uwa4d.com/archives/allinone.html
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.