Performance can be saved by having multiple objects share the result of some calculation; of course, this only works if all of them would generate the same result. Such situations are often easy to spot, but can be tricky to refactor, and so exploiting this would be very implementation dependent. 

Some examples might include finding an object in a Scene, reading data from a file, parsing data (such as XML or JSON), finding something in a big list or deep dictionary of information, calculating pathing for a group of Artificial Intelligence (AI) objects, complex mathematics-like trajectories, raycasting, and so on.

Think about each time an expensive operation is undertaken, and consider whether it is being called from multiple locations but always results in the same output. If this is the case, then it would be wise to restructure things so that the result is calculated once and then distributed to every object that needs it in order to minimize the amount of recalculation...

Another habit that's easy to fall into is to call something repeatedly in an Update() callback way more often than is needed. For example, we may start with a situation like this:

void Update() {
  ProcessAI();
}

In this case, we're calling some custom ProcessAI() subroutine every single frame. This may be a complex task, requiring the AI system to check some grid system to figure out where it's meant to move or determine some fleet maneuvers for a group of spaceships or whatever our game needs for its AI.

If this activity is eating into our frame rate budget too much, and the task can be completed less frequently than every frame with no significant drawbacks, then a good trick to improve performance is to simply reduce the frequency that ProcessAI() gets called:

private float _aiProcessDelay = 0.2f;
private float _timer = 0.0f;

void Update() {
  _timer += Time.deltaTime;
  if (_timer > _aiProcessDelay) {
    ProcessAI();
    _timer -= _aiProcessDelay...

It turns out that performing a null reference check against a GameObject will result in some unnecessary performance overhead. GameObjects and MonoBehaviours are special objects compared to a typical C# object in that they have two representations in memory: one exists within the memory managed by the same system managing the C# code we write (Managed code), whereas the other exists in a different memory space which is handled separately (Native code). Data can move between these two memory spaces, but each time this happens will result in some additional CPU overhead and possibly an extra memory allocation.

This effect is commonly referred to as crossing the Native-Managed Bridge. If this happens, it is likely to generate an additional memory allocation for an object’s data to get copied across the Bridge, which will require the Garbage Collector to eventually perform some automatic cleanup of memory for us. This subject will be explored in much more...

Ordinarily, retrieving a string property from an object is the same as retrieving any other reference type property in C#; it should be acquired with no additional memory cost. However, retrieving string properties from GameObjects is another subtle way of accidentally crossing over the Native-Managed Bridge.

The two properties of GameObject affected by this behavior are tag and name. Therefore, it is unwise to use either properties during gameplay, and you should only use them in performance-inconsequential areas, such as Editor Scripts. However, the Tag System is commonly used for runtime identification of objects, which can make this a significant problem for some teams.

For example, the following code would cause an additional memory allocation during every iteration of the loop:

for (int i = 0; i < listOfObjects.Count; ++i) {
  if (listOfObjects[i].tag == "Player") {
    // do something with this object
  }
}

It is often a better practice...

C# offers many different data structures in the System.Collections namespace and we shouldn't become too accustomed with using the same ones over and over again. A common performance problem in software development is making use of an inappropriate data structure for the problem we're trying to solve simply because its convenient. The two most commonly used are perhaps lists (List<T>), and dictionaries (Dictionary<K,V>).

If we want to iterate through a set of objects then a list is preferred, since it is effectively a dynamic array where the objects and/or references reside next to one another in memory, and therefore iteration causes minimal cache misses. Dictionaries are best used if two objects are associated with one-another and we wish to acquire, insert, or remove these associations quickly. For example, we might associate a level number with a particular Scene file, or an enum representing different body parts on a character, with Collider...

In earlier versions of Unity (version 5.3 and older), the references to Transform Components would be laid out in memory in a generally random order. This meant that iteration over multiple Transforms was fairly slow due to the likelihood of cache-misses. The upside was that re-parenting a GameObject to another one wouldn't really cause a significant performance hit since the Transforms operated a lot like a Heap data structure which tend to be relatively fast at insertion and deletion. This behaviour wasn't something we could control, and so we simply lived with it.

However, since Unity 5.4 and beyond, the Transform Component's memory layout has changed significantly. Since then, a Transform Component's parent-child relationships have operated more like dynamic arrays, whereby Unity attempts to store all Transforms that share the same parent sequentially in memory inside a pre-allocated memory buffer and are sorted by their depth in the Hierarchy...

The Transform Component stores data only relative to its own parent. This means that accessing and modifying a Transform Component's position, rotation, and/or scale properties can potentially result in a lot of unanticipated matrix multiplication calculations to generate the correct Transform representation for the object through its parent Transforms. The deeper the object is in the Hierarchy window, the more calculations are needed to determine the final result. 

However, this also means that using localPosition, localRotation, and localScale have a relatively trivial cost associated with them, since these are the values stored directly in the given Transform and can be retrieved without any additional matrix multiplication. Therefore, these local property values should be used whenever possible.

Unfortunately, changing our mathematical calculations from world-space to local-space can over-complicate what were originally simple (and solved) problems, so...

The SendMessage() method and family of GameObject.Find() methods are notoriously expensive and should be avoided at all costs. The SendMessage() method is about 2,000 times slower than a simple function call, and the cost of the Find() method scales very poorly with Scene complexity since it must iterate through every GameObject in the Scene. It is sometimes forgivable to call Find() during initialization of a Scene, such as during an Awake() or Start() callback. Even in this case, it should only be used to acquire objects that we know for certain already exist in the Scene and for scenes that have only a handful of GameObjects in them. Regardless, using either of these methods for interobject communication at runtime is likely to generate a very noticeable overhead and potentially dropped frames.

Relying on Find() and SendMessage() is typically symptomatic of poor design, inexperience in programming with C# and Unity, or just plain laziness during...

Scenes can get pretty busy sometimes, especially when we're building large, open worlds. The more objects invoking code in an Update() callback, the worse things it will scale and the slower the game becomes. However, much of what is being processed may be completely unnecessary if it is outside of the player's view or simply too far away to matter. This may not be a possibility in large city-building simulation games, where the entire simulation must be processed at all times, but it is often possible in first-person and racing games since the player is wandering around a large expansive area, where non-visible objects can be temporarily disabled without having any noticeable effect on gameplay.

It is safe to say that CPUs are relatively good at multiplying floating-point numbers together, but relatively dreadful at calculating square-roots from them. Every time we ask a Vector3 to calculate a distance with the magnitude property or with the Distance() method, we're asking it to perform a square-root calculation (as per Pythagorean theorem), which can cost a lot of CPU overhead compared to many other types of vector math calculations.

However, the Vector3 class also offers a sqrMagnitude property, which provides the same result as distance, only the value is squared. This means that if we also square the value we wish to compare distance against, then we can perform essentially the same comparison without the cost of an expensive square-root calculation.

For example, consider the following code:

float distance = (transform.position – other.transform.position).Distance();
if (distance < targetDistance) {
  // do stuff
}

This can be replaced...

Unity's Serialization system is mainly used for Scenes, Prefabs, ScriptableObjects and various Asset types (which tend to derive from ScriptableObject). When one of these object types is saved to disk, it is converted into a text file using the Yet Another Markup Language (YAML) format, which can be deserialized back into the original object type at a later time. All GameObjects and their properties get serialized when a Prefab or Scene is serialized, including private and protected fields, all of their Components as well as its child GameObjects and their Components, and so on.

When our application is built, this serialized data is bundled together in large binary data files internally called Serialized Files in Unity. Reading and deserializing this data from disk at runtime is an incredibly slow process (relatively speaking) and so all deserialization activity comes with a significant performance cost.

This kind of deserialization takes place any time we...

Scenes can be loaded either to replace the current Scene or can be loaded additively to add its contents to the current Scene without unloading the preceding one. This can be toggled via the LoadSceneMode argument of the SceneManager.LoadScene() family of functions. 

Another mode of Scene loading is to complete it either synchronously or asynchronously, and there are good reasons to use both. Synchronous loading is the typical means of loading a Scene by calling SceneManager.LoadScene() where the main thread will block until the given Scene completes loading. This normally results in a poor user experience, as the game appears to freeze as the contents are loaded in (whether as a replacement or additively). This is best used if we want to get the player into the action as soon as possible, or we have no time to wait for Scene objects to appear. This would normally be used if we’re loading into the first level of the game or returning to the main menu...

Earlier in this chapter, in the 

 section, we discussed the relative pros and cons of using these Unity Engine features as a means of avoiding excessive CPU workload during most of our frames. Regardless of which of these approaches we might adopt, there is an additional risk of having lots of MonoBehaviours written to periodically call some function, which is having too many methods triggering in the same frame simultaneously.

Imagine thousands of MonoBehaviours that initialized together at the start of a Scene, each starting a Coroutine at the same time that will process their AI tasks every 500 milliseconds. It is highly likely that they would all trigger within the same frame, causing a huge spike in its CPU usage for a moment, which settles down temporarily and then spikes again a few moments later when the next round of AI processing is due. Ideally, we would want to spread these invocations out over time.

The following...

This chapter introduced you to many methods that improve your scripting practices in the Unity Engine, with the aim of improving performance if (and only if) you have already proven them to be the cause of a performance problem. Some of these techniques demand some forethought and profiling investigation before being implemented, since they often come with introducing additional risks or obfuscating our codebase for new developers. Workflow is often just as important as performance and design, so before you make any performance changes to the code, you should consider whether or not you're sacrificing too much on the altar of performance optimization.

We will investigate more advanced scripting improvement techniques later, in Chapter 8, Masterful Memory Management, but let's take a break from staring at code and explore some ways to improve graphics performance using a pair of built-in Unity features known as Dynamic Batching and Static Batching.