When we create new MonoBehaviour script files in Unity, whether we're using Unity 4 or Unity 5, it creates two boilerplate methods for us:

// Use this for initialization
void Start () {

}

// Update is called once per frame
void Update () {

}

The Unity engine hooks in to these methods during initialization and adds them to a list of methods to call back at key moments. However, if we leave these as empty declarations in our codebase, then they will cost us a small overhead whenever the engine invokes them.

The Start() method is only called when the GameObject is instantiated for the first time, which can be whenever the scene is loaded or a new GameObject is instantiated from a Prefab. Therefore, leaving the empty Start() declaration may not be particularly noticeable unless there's a lot of GameObjects in the scene invoking them at startup time. However, it also adds unnecessary overhead to any GameObject.Instantiate() call, which typically happens during key events, so they can potentially contribute to, and exacerbate, already poor performances situation when lots of events are happening simultaneously.

Meanwhile, the Update() method is called every time the scene is rendered. If our scene contains thousands of GameObjects owning components with these empty Update() declarations, then we can be wasting a lot of CPU cycles and causing havoc on our frame rate.

Let's prove this with a simple test. Our test scene should have GameObjects with two types of Component, one type with an empty Update() declaration, and another with no methods defined:

public class CallbackTestComponent : MonoBehaviour {
  void Update () {}
}

public class EmptyTestComponent : MonoBehaviour {
}

Here are the test results for 32,768 Components of each type. If we enable all objects with no stub methods during runtime, then nothing interesting happens with CPU usage in the Profiler. We may notice some memory consumption changes and some slightly different VSync activity, but nothing very concerning. However, as soon as we enable all the objects with empty Unity callback declarations, we will observe a huge increase in CPU usage:

The fix for this is simple; delete the empty declarations. Unity will have nothing to hook into, and nothing will be called. Sometimes, finding such empty declarations in an expansive codebase can be difficult, but using some basic regular expressions (regex), we should be able to find what we're looking for relatively easily.

The following regex search should find any empty Update() declarations in our code:

voids*Updates*?(s*?)s*?
*?{
*?s*?}

This regex checks for a standard method definition of the Update() method, while including any surplus whitespace and newline characters that can be distributed throughout the method declaration.

Naturally, all of the above is also true for the non-boilerplate Unity callbacks, such as OnGUI(), OnEnable(), OnDestroy(), FixedUpdate(), and so on. Check the MonoBehaviour Unity Documentation page for a complete list of these callbacks at http://docs.unity3d.com/ScriptReference/MonoBehaviour.html.

It might seem unlikely that someone generated empty versions of these callbacks in our codebase, but never say never. For example, if we use a common base class MonoBehaviour throughout all of our custom components, then a single empty callback declaration in that base class will permeate the entire game, which can cost us dearly. Be particularly careful of the OnGUI() method, as it can be invoked multiple times within the same frame or user interface (UI) event.