Optimizing Performance in iOS Part3:Optimizing Script Performance

Optimizing Script Performance

This page gives some general hints for how to improve script performance on iOS.

Reduce Fixed Delta Time

Use a fixed delta time of 15-25 fps. You can change this in Edit->Project Settings->Time. This reduces how often FixedUpdate is called and how often the physics engine has to perform collision detection and rigidbody updates. If you are using rigidbodies for the main character, you can enable interpolation in the Rigidbody Component to smooth out low fixed delta time steps.

 

Reduce GetComponent Calls

Using GetComponent or BuiltIn component accessors can have a noticeable overhead. You can reduce it by caching a direct reference to the component.

For example:

function Update () {
    transform.Translate(0, 1, 0);
}

You can optimize your script to this instead:

myTransform : Transform;
function Awake () {
   myTransform = transform;
}
function Update () {
    myTransform.Translate(0, 1, 0);
}

 

Avoid Allocating Memory

• Minimize your allocations in scripts.
• Use structs. Structs do not allocate memory, instead they are placed on the stack and are passed by value which is fast.

 

Reduce the GUI

• Don't use GUILayout, use GUI functions instead and minimize the amount of GUI on screen
• Use MonoBehaviour.useGUILayout = false; to minimize GUI overhead

function Awake () {
    useGUILayout = false;
}

 

 

Use iOS Script Call Optimization

Most of the functions in UnityEngine namespace are implemented in C/C++. Calling such functions from scripts has additional performance overhead. Consider using iOS Script Call optimization in Edit->Project Settings->Player to gain several extra milliseconds per frame:

• Slow and Safe - default mono internal call handling with exception support.
• Fast and Exceptions Unsupported - fast mono internal call implementation, but exceptions are not supported, so use it with care. A typical scenario when it could be useful: application deals a lot with Unity Engine and does not throw any exceptions. This option could save 1-4 ms / frame.

Optimizing Garbage Collection

• As mentioned above ,try avoiding any allocations
• If allocations can't be avoided then there are two allocation/collection strategies:
  • small heap fast and frequent garbage collection
    This strategy might work well for games that have long action gameplay and needs smooth framerate.
    Typical heap for Unity iOS game which allocates small blocks for short period of time often is ~200 KB, garbage collection of such heap takes ~5ms (on iPhone 3G). With a 1 MB heap the duration of garbage collection increases to ~7 ms.
    Sometimes it can be useful to force garbage collection every Nth frame:
    

    if (Time.frameCount % 30 == 0)
    {
       System.GC.Collect();
    }
    

    But use it with care, watch internal profiler statistics, and make decisions based on them.
  • large heap slow and rare garbage collection
    This strategy might work for games that are have short to medium length smooth framerate demanding gameplay. The idea is to avoid garbage collection while gameplay is running and make garbage collections during gameplay pauses. It is good idea to preallocate some space on the heap during startup which is large enough to survive gameplay sessions yet small enough to avoid application killing by OS because of low system memory. Mono tries to expand the heap only when necessary, so sometimes it is good idea to force its expansion on startup:
    

    function Start() {
            var tmp = new System.Object[1024];
            // make allocations in smaller blocks to avoid them to be treated in a special way, which is designed for large blocks
            for (var i : int = 0; i < 1024; i++)
                    tmp[i] = new byte[1024];
            // release reference
            tmp = null;
    }
    

    Later, you can force garbage collection when gameplay is paused:
    

    System.GC.Collect();
    

    Use this with care, pay attention to internal profiler statistics, and make decisions based on the actual numbers.