第10章　Tuning Practice - Script (C#)

本章では、主にC#コードのパフォーマンスチューニング手法について実例を交えながら紹介します。C#の基礎的な記法についてはここでは扱わず、パフォーマンスを要求されるようなゲームの開発において意識すべき設計や実装について解説します。

10.1　GC.Allocするケースと対処法

「2.5.2 ガベージコレクション」で紹介しましたが、本節では具体的にどのような処理を行ったときにGC.Allocをするのか、まずは理解していきましょう。

10.1.1　参照型のnew

まずはとてもわかりやすくGC.Allocが発生するケースです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private void Update()
{
    const int listCapacity = 100;
    // List<int>のnewでGC.Alloc
    var list = new List<int>(listCapacity);
    for (var index = 0; index < listCapacity; index++)
    {
        // 特に意味はないがindexをListに詰める
        list.Add(index);
    }
    // listから値をランダムに取り出す
    var random = UnityEngine.Random.Range(0, listCapacity);
    var randomValue = list[random];
    // ... ランダムな値から何かする ...
}

このコードの大きな問題点は、毎フレーム実行されるUpdateメソッドで、List<int>をnewしている点です。

こちらを修正するには、List<int>を事前に生成して使い回すことで毎フレームのGC.Allocを回避することが可能です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private static readonly int listCapacity = 100;
// 事前にListを生成しておく
private readonly List<int> _list = new List<int>(listCapacity);

private void Update()
{
    _list.Clear();
    for (var index = 0; index < listCapacity; index++)
    {
        // 特に意味はないけどindexをListに詰めていく
        _list.Add(index);
    }
    // listから値をランダムに取り出す
    var random = UnityEngine.Random.Range(0, listCapacity);
    var randomValue = _list[random];
    // ... ランダムな値から何かする ...
}

こちらのサンプルコードのような無意味なコードを書くことはないと思いますが、類似した例は想像よりも見つかるケースが多いです。

1
2

var randomValue = UnityEngine.Random.Range(0, listCapacity);
// ... ランダムな値から何かする ...

10.1.2　ラムダ式

ラムダ式も便利な機能ですが、こちらも使い方によってはGC.Allocが発生してしまうため、ゲームでは使用できる場面は限られます。ここでは、次のようなコードが定義されている前提とします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// メンバー変数
private int _memberCount = 0;

// static変数
private static int _staticCount = 0;

// メンバーメソッド
private void IncrementMemberCount()
{
    _memberCount++;
}

// staticメソッド
private static void IncrementStaticCount()
{
    _staticCount++;
}

// 受け取ったActionをInvokeするだけのメンバーメソッド
private void InvokeActionMethod(System.Action action)
{
    action.Invoke();
}

このとき、次のようにラムダ式内で変数を参照した場合、GC.Allocが発生します。

1
2
3
4
5
6
7

// メンバー変数を参照した場合、Delegate Allocationが発生
InvokeActionMethod(() => { _memberCount++; });

// ローカル変数を参照した場合、Closure Allocationが発生
int count = 0;
// 上記と同じDelegate Allocationも発生
InvokeActionMethod(() => { count++; });

ただし、以下のようにstatic変数を参照すると、これらのGC.Allocを回避できます。

1
2

// static変数を参照した場合、GC Allocは発生せず
InvokeActionMethod(() => { _staticCount++; });

ラムダ式内でのメソッド参照も記述方法によってGC.Allocのされ方が異なります。

1
2
3
4
5
6
7
8

// メンバーメソッドを参照した場合、Delegate Allocationが発生
InvokeActionMethod(() => { IncrementMemberCount(); });

// メンバーメソッドを直接指定した場合、Delegate Allocationが発生
InvokeActionMethod(IncrementMemberCount);

// staticメソッドを直接指定した場合、Delegate Allocationが発生
InvokeActionMethod(IncrementStaticCount);

これらを回避するためには、以下のようにステートメント形式でstaticメソッドを参照する必要があります。

1
2

// ラムダ式内でstaticメソッドを参照した場合は、Non Allocとなる
InvokeActionMethod(() => { IncrementStaticCount(); });

こうすることで初回のみActionがnewされますが、内部的にキャッシュされることによって2回目以降GC.Allocが回避されます。

しかし、すべての変数やメソッドをstaticにすることはコードの安全性や可読性の面からとても採用できるものではありません。高速化が必要なコードでは、staticを多用してGC.Allocを無くすよりも毎フレームもしくは不定なタイミングで発火するイベントなどはラムダ式を使わずに設計する方が安全と言えるでしょう。

10.1.3　ジェネリックを使用してボックス化するケース

ジェネリックを使用した以下の場合、何が原因でボックス化する可能性があるでしょうか。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public readonly struct GenericStruct<T> : IEquatable<T>
{
    private readonly T _value;

    public GenericStruct(T value)
    {
        _value = value;
    }

    public bool Equals(T other)
    {
        var result = _value.Equals(other);
        return result;
    }
}

このケースでは、プログラマーはGenericStructにIEquatable<T>インターフェイスの実装をしましたが、Tに制限を設けるのを忘れてしまいました。その結果、IEquatable<T>インターフェイスの実装がされていない型をTに指定できてしまい、Object型へ暗黙的にキャストされて以下のEqualsが使われるケースが存在してしまいます。

1

public virtual bool Equals(object obj);

たとえばIEquatable<T>インターフェイスの実装がされていないstructをTに指定すると、Equalsの引数でobjectにキャストされることになるため、ボックス化が発生します。これが起こらないように事前に対策するには、次のように変更します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public readonly struct GenericOnlyStruct<T> : IEquatable<T>
    where T : IEquatable<T>
{
    private readonly T _value;

    public GenericOnlyStruct(T value)
    {
        _value = value;
    }

    public bool Equals(T other)
    {
        var result = _value.Equals(other);
        return result;
    }
}

where句（ジェネリック型制約）を用いて、Tが受け入れられる型をIEquatable<T>を実装している型に制限してあげることで、こうした予期せぬボックス化を未然に防ぐことができます。

10.2　for/foreachについて

「2.6 アルゴリズムと計算量」で紹介したようにループはデータ数に依存して時間がかかるようになります。また、一見同じような処理に見えるループもコードの書き方次第で効率が変わります。

ここでは、SharpLab*1を利用して、foreach/forを使用したListや配列の中身を1つずつ取得するだけのコードをILからC#にデコンパイルした結果を見てみましょう。

まずはforeachでループを回した場合を見てみましょう。Listへの値の追加などは省略してます。

1
2
3
4

var list = new List<int>(128);
foreach (var val in list)
{
}

1
2
3
4
5
6
7
8
9
10
11
12

List<int>.Enumerator enumerator = new List<int>(128).GetEnumerator();
try
{
    while (enumerator.MoveNext())
    {
        int current = enumerator.Current;
    }
}
finally
{
    ((IDisposable)enumerator).Dispose();
}

foreachで回した場合は、列挙子を取得してMoveNext()で次へ進めてCurrentで値を参照する実装になっていることがわかります。さらに、list.cs*2のMoveNext()の実装を見ると、サイズのチェックなど各種プロパティアクセス回数が多くなっており、インデクサーによる直アクセスより処理が多くなるように見えます。

次に、forで回したときを見てみましょう。

1
2
3
4
5

var list = new List<int>(128);
for (var i = 0; i < list.Count; i++)
{
    var val = list[i];
}

1
2
3
4
5
6
7

List<int> list = new List<int>(128);
int num = 0;
while (num < list.Count)
{
    int num2 = list[num];
    num++;
}

C#ではfor文はwhile文の糖衣構文であり、インデクサー（public T this[int index]）による参照で取得されていることがわかります。また、このwhile文をよく見ると、条件式にlist.Countが入っています。つまり、Countプロパティへのアクセスがループを繰り返すたびに行われることになります。Countの数が多くなればなるほど、Countプロパティへのアクセス回数が比例して増加し、数によっては無視できない負荷になっていきます。もし、ループ内でCountが変わらないのであれば、ループの前でキャッシュしておくことでプロパティアクセスの負荷を削減できます。

1
2
3
4
5

var count = list.Count;
for (var i = 0; i < count; i++)
{
    var val = list[i];
}

1
2
3
4
5
6
7
8

List<int> list = new List<int>(128);
int count = list.Count;
int num = 0;
while (num < count)
{
    int num2 = list[num];
    num++;
}

Countをキャッシュすることでプロパティアクセス回数が削減され、高速化されました。今回のループ中の比較はどちらもGC.Allocによる負荷はなく、実装内容の違いによる差分となります。

また、配列の場合はforeachも最適化されており、forで記述したものとほぼ変化はないものとなります。

1
2
3
4

var array = new int[128];
foreach (var val in array)
{
}

1
2
3
4
5
6
7

int[] array = new int[128];
int num = 0;
while (num < array.Length)
{
    int num2 = array[num];
    num++;
}

検証のため、データ数10,000,000として事前にランダムな数値をアサインし、List<int>データの和を計算するものとしました。検証環境はPixel 3a、Unity 2021.3.1f1で実施しました。

List<int>の場合は、条件を細かく揃えて比較してみるとforeachよりもfor、Countの最適化を施したforのほうがさらに速くなったことがわかります。Listのforeachは、Countの最適化を施したforに書き換えることで、foreachの処理におけるMoveNext()やCurrentプロパティのオーバーヘッドを削減し、高速化が可能です。

また、Listと配列のそれぞれ最速同士で比較すると、Listより配列のほうが約2.3倍以上高速になりました。foreachとforでILが同じ結果になるように記述しても、foreachが速い結果となり、配列のforeachが十分に最適化されていると言えるでしょう。

以上の結果から、データ数が多くかつ処理速度を高速にしなければならない場面についてはList<T>ではなく配列を検討すべきでしょう。しかし、フィールドに定義したListをローカルキャッシュせずそのまま参照してしまうなど、書き換えが不十分な場合は高速化できないこともありますので、foreachからforに変更する際には必ず計測をしつつ適切に書き換えましょう。

10.3　オブジェクトプーリング

随所で触れてきましたが、ゲーム開発では動的にオブジェクトを生成せずに、事前生成して使い回すことが重要です。これをオブジェクトプーリングと呼びます。たとえば、ゲームフェーズで使用予定のオブジェクトをロードフェーズでまとめて生成してプーリングしておき、使用するときはプールしているオブジェクトへの代入と参照のみ行いながら扱うことで、ゲームフェーズ中のGC.Allocを避けることが可能です。

また、オブジェクトプーリングはアロケーションの削減の他にも、画面を構成するオブジェクトを都度作り直すことなく画面遷移を可能にしておくことでロード時間の短縮を実現したり、計算コストが非常に高い処理の結果を保持しておいて重い計算を複数回実行することを避けたり、さまざまな場面で用いられます。

ここでは広義にオブジェクトと表現しましたが、これは最小単位のデータに留まらず、CoroutineやActionなどにも該当します。たとえば、事前にCoroutineを想定される実行数分以上生成しておき、必要なタイミングで使用して使い潰していくようなことも検討しましょう。2分間で終わるゲームで最大で20回実行されるようなときはIEnumeratorをそれぞれ先に生成しておき、使用する時はStartCoroutineするだけにすることで生成コストは抑えられます。

10.4　string

stringオブジェクトは文字列を表すSystem.Charオブジェクトのシーケンシャルコレクションです。stringは使い方1つでGC.Allocが簡単に起こります。たとえば、文字連結演算子+を利用して2つの文字列の連結をすると、新しいstringオブジェクトを生成することになります。stringの値は生成後に変更できない（イミュータブル）ため、値の変更が行われているように見える操作は新しいstringオブジェクトを生成して返しています。

1
2
3
4
5
6
7
8
9

private string CreatePath()
{
    var path = "root";
    path += "/";
    path += "Hoge";
    path += "/";
    path += "Fuga";
    return path;
}

上記例の場合は、各文字列結合でstringが生成されていき、合計で164Byteアロケーションが発生します。

文字列が頻繁に変更されるときは、値が変更可能なStringBuilderを利用することでstringオブジェクトの大量生成を防ぐことができます。文字連結や削除などの操作をStringBuilderオブジェクトで行い、最終的に値を取り出してstringオブジェクトにToString()することで、取得時のみのメモリアロケーションに抑えることができます。また、StringBuilderを使用する際には、Capacityを必ず設定するようにしましょう。未指定のときは初期値が16になり、Appendなどで文字数が増えバッファーが拡張されるときにメモリの確保と値のコピーが走るため、不用意な拡張が発生しない適切なCapacityを設定するようにしましょう。

1
2
3
4
5
6
7
8
9
10
11

private readonly StringBuilder _stringBuilder = new StringBuilder(16);
private string CreatePathFromStringBuilder()
{
    _stringBuilder.Clear();
    _stringBuilder.Append("root");
    _stringBuilder.Append("/");
    _stringBuilder.Append("Hoge");
    _stringBuilder.Append("/");
    _stringBuilder.Append("Fuga");
    return _stringBuilder.ToString();
}

StringBuilderを用いた例では、事前にStringBuilderを生成（上記例の場合、生成時に112Byteアロケーション）しておけば、以降は生成した文字列を取り出すToString()時に掛かる50Byteのアロケーションで済みます。

ただし、StringBuilderも値の操作中にアロケーションが起こりにくいだけで、前述のようにToString()実行時にはstringオブジェクトを生成することになるため、GC.Allocを避けたいときに使用するのは推奨されません。また、$""構文はstring.Formatに変換され、string.Formatの内部実装はStringBuilderが使われているため、結局はToString()のコストは避けられません。前項のオブジェクトの使い回しをここでも応用し、あらかじめ使用される可能性のある文字列はstringオブジェクトを事前に生成し、それを使うようにしましょう。

しかしながらゲーム中に文字列操作とstringオブジェクトの生成をどうしても行わなければならない場合もあります。そういう場合には、文字列用のバッファーを事前に持っておいて、そのバッファーをそのまま使えるようにするような拡張を行う必要があります。unsafeなコードを自前で実装するか、ZString*3のようなUnity向けの拡張機能（たとえばTextMeshProへのNonAllocな適用機能）を備えたライブラリの導入を検討しましょう。

10.5　LINQと遅延評価

本節ではLINQの使用によるGC.Allocを軽減する方法と遅延評価のポイントについて解説します。

10.5.1　LINQの使用によるGC.Allocを軽減する

LINQの使用では、リスト10.22のような場合にGC.Allocが発生します。

1
2

var oneToTen = Enumerable.Range(1, 11).ToArray();
var query = oneToTen.Where(i => i % 2 == 0).Select(i => i * i);

リスト10.22でGC.Allocが発生する理由はLINQの内部実装に起因します。加えて、LINQの一部メソッドは呼び出し側の型に合わせた最適化を行うため、呼び出し元の型によってGC.Allocのサイズが変化します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

private int[] array;
private List<int> list;
private IEnumerable<int> ienumerable;

public void GlobalSetup()
{
    array = Enumerable.Range(0, 1000).ToArray();
    list = Enumerable.Range(0, 1000).ToList();
    ienumerable = Enumerable.Range(0, 1000);
}

public void RunAsArray()
{
    var query = array.Where(i => i % 2 == 0);
    foreach (var i in query){}
}

public void RunAsList()
{
    var query = list.Where(i => i % 2 == 0);
    foreach (var i in query){}
}

public void RunAsIEnumerable()
{
    var query = ienumerable.Where(i => i % 2 == 0);
    foreach (var i in query){}
}

リスト10.23に定義した各メソッドのベンチマークを測定すると図10.1のような結果が得られました。この結果からT[] → List<T> → IEnumerable<T>の順番にヒープアロケーションのサイズが大きくなっていることがわかります。

このように、LINQを使用する場合は、実行時の型を意識することでGC.Allocのサイズを削減することができます。

図10.1: 型ごとの実行速度比較

10.5.2　LINQの遅延評価

LINQのWhereやSelectといったメソッドは、実際に結果が必要になるまで評価を遅らせる遅延評価となっています。一方で、ToArrayのような即時評価となるメソッドも定義されています。

ここで、下記のリスト10.24のコードの場合を考えます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

private static void LazyExpression()
{
    var array = Enumerable.Range(0, 5).ToArray();
    var sw = Stopwatch.StartNew();
    var query = array.Where(i => i % 2 == 0).Select(HeavyProcess).ToArray();
    Console.WriteLine($"Query: {sw.ElapsedMilliseconds}");

    foreach (var i in query)
    {
        Console.WriteLine($"diff: {sw.ElapsedMilliseconds}");
    }
}

private static int HeavyProcess(int x)
{
    Thread.Sleep(1000);
    return x;
}

リスト10.24の実行結果がリスト10.25になります。即時評価となるToArrayを末尾に追加したことで、queryへの代入時にWhereやSelectのメソッドを実行し値を評価した結果が返されます。そのためHeavyProcessも呼び出されるので、queryを生成するタイミングで処理時間がかかっていることがわかります。

1
2
3
4

Query: 3013
diff: 3032
diff: 3032
diff: 3032

このようにLINQの即時評価のメソッドを意図せず呼び出してしまうとその箇所がボトルネックになってしまう可能性があります。ToArrayやOrderBy, Countなどシーケンスすべてを一度見る必要があるメソッドは即時評価となるため、呼び出し時のコストを意識して使用しましょう。

10.5.3　「LINQの使用を避ける」という選択

LINQを使用した際のGC.Allocの原因や軽減方法、遅延評価のポイントについて解説しました。本節ではLINQを使用する基準について解説します。前提としてLINQは便利な言語機能ではありますが、使用するとヒープアロケーションや実行速度は使用しない場合に比べて悪化します。実際にMicrosoftのUnityのパフォーマンスに関する推奨事項*4では「Avoid use of LINQ」と明記されています。LINQを使用した場合と、使用しない場合で同じロジックを実装した場合のベンチマークをリスト10.26で比較してみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

private int[] array;

public void GlobalSetup()
{
    array = Enumerable.Range(0, 100_000_000).ToArray();
}

public void Pure()
{
    foreach (var i in array)
    {
        if (i % 2 == 0)
        {
            var _ = i * i;
        }
    }
}

public void UseLinq()
{
    var query = array.Where(i => i % 2 == 0).Select(i => i * i);
    foreach (var i in query)
    {
    }
}

結果は図10.2になります。実行時間を比較するとLINQを使用しない場合に対してLINQを使った処理は19倍ほど時間がかかってしまっていることがわかります。

図10.2: LINQの使用有無によるパフォーマンス比較結果

上記の結果からLINQを使用することによるパフォーマンスの悪化は明確ですが、LINQを使用することでコーディングの意図が伝わりやすい場合などもあります。これらの挙動を把握した上で、LINQを使用するか、使用する場合のルールなどはプロジェクト内で議論の余地があるかと思います。

10.6　async/awaitのオーバーヘッドの避け方

async/awaitはC#5.0で追加された言語機能であり、非同期処理をコールバックを使わず一筋の同期的処理のように記述できるものです。

10.6.1　不要な箇所でのasyncを避ける

asyncを定義されたメソッドは、コンパイラによって非同期処理を実現するためのコードが生成されます。そしてasyncキーワードがあれば、コンパイラによるコード生成は必ず行われます。そのため、リスト10.27のように同期的に完了する可能性のあるメソッドも実際にはコンパイラによるコード生成が行われています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

using System;
using System.Threading.Tasks;

namespace A {
    public class B {
        public async Task HogeAsync(int i) {
            if (i == 0) {
                Console.WriteLine("i is 0");
                return;
            }
            await Task.Delay(TimeSpan.FromSeconds(1));
        }

        public void Main() {
            int i = int.Parse(Console.ReadLine());
            Task.Run(() => HogeAsync(i));
        }
    }
}

このリスト10.27のような場合は、同期的に終了する可能性のあるHogeAsyncを分割し、リスト10.28のように実装することで同期的に完了する場合に不要なIAsyncStateMachine実装のステートマシン構造体を生成するコストを省略できます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

using System;
using System.Threading.Tasks;

namespace A {
    public class B {
        public async Task HogeAsync(int i) {
            await Task.Delay(TimeSpan.FromSeconds(1));
        }

        public void Main() {
            int i = int.Parse(Console.ReadLine());
            if (i == 0) {
                Console.WriteLine("i is 0");
            } else {
                Task.Run(() => HogeAsync(i));
            }
        }
    }
}

10.6.2　同期コンテキストのキャプチャを避ける

別スレッドに退避させた非同期処理から、呼び出し元のスレッドに復帰する仕組みが同期コンテキストであり、awaitを使用することで直前のコンテキストをキャプチャーできます。この同期コンテキストのキャプチャはawaitのたびに行われるため、awaitごとのオーバーヘッドが発生します。そのため、Unityでの開発に広く利用されているUniTask*5では、同期コンテキストのキャプチャによるオーバーヘッドを避けるためにExecutionContextとSynchronizationContextを使用しない実装となっています。Unityに関してはこのようなライブラリを導入することで、パフォーマンスの改善が見られる場合があります。

10.7　stackallocによる最適化

配列の確保は通常ヒープ領域に確保されるため、ローカル変数として配列を確保すると、都度GC.Allocが発生してスパイクの原因となります。また、ヒープ領域への読み書きはスタック領域と比べると、少しですが効率が悪くなります。

そのためC#では、unsafeコード限定で、スタック上に配列を確保するための構文が用意されています。

リスト10.29のように、newキーワードを用いる代わりに、stackallocキーワードを用いて配列を確保すると、スタック上に配列が確保されます。

1
2
3
4
5
6

// stackallocはunsafe限定
unsafe
{
    // スタック上にintの配列を確保
    byte* buffer = stackalloc byte[BufferSize];
}

C# 7.2からSpan<T>構造体を用いることで、リスト10.30に示すようにunsafeなしでstackallocを利用できるようになりました。

1

Span<byte> buffer = stackalloc byte[BufferSize];

Unityの場合は2021.2から標準で利用できます。それ以前バージョンの場合はSpan<T>が存在しないため、System.Memory.dllを導入する必要があります。

stackallocで確保した配列はスタック専用なため、クラスや構造体のフィールドに持てません。必ずローカル変数として使う必要があります。

スタック上への確保とはいえ、要素数が大きい配列の確保はそれなりに処理時間がかかります。もしUpdateループ内などのヒープアロケーションを避けたい箇所で要素数の大きい配列を利用したい場合は、初期化時の事前確保か、オブジェクトプールのようなデータ構造を用意して、利用時に貸し出すような実装のほうがよいでしょう。

また、stackallocで確保したスタック領域は、関数を抜けるまで解放されない点に注意が必要です。たとえばリスト10.31に示すコードは、ループ内で確保した配列はすべて保持され、Hogeメソッドを抜けるときに解放されるので、ループを回しているうちにStack Overflowを起こす可能性があります。

1
2
3
4
5
6
7
8

unsafe void Hoge()
{
    for (int i = 0; i < 10000; i++)
    {
        // ループ数分配列が蓄積される
        byte* buffer = stackalloc byte[10000];
    }
}

10.8　sealedによるIL2CPPバックエンド下でのメソッド呼び出しの最適化

UnityでIL2CPPをバックエンドとしてビルドをすると、クラスのvirtualなメソッド呼び出しを実現するために、C++のvtableのような仕組みを用いてメソッド呼び出しを行います*6。

具体的には、クラスのメソッド呼び出しの定義ごとに、リスト10.32に示すようなコードが自動生成されます。

1
2
3
4
5
6
7
8
9
10
11
12

struct VirtActionInvoker0
{
    typedef void (*Action)(void*, const RuntimeMethod*);

    static inline void Invoke (
        Il2CppMethodSlot slot, RuntimeObject* obj)
    {
        const VirtualInvokeData& invokeData =
            il2cpp_codegen_get_virtual_invoke_data(slot, obj);
        ((Action)invokeData.methodPtr)(obj, invokeData.method);
    }
};

これはvirutalなメソッドだけでなく、コンパイル時に継承をしていない、virtualでないメソッドであっても同様なC++コードを生成します。このような自動生成の挙動によって、コードサイズが肥大化したり、メソッド呼び出しの処理時間が増大します。

この問題は、クラスの定義にsealed修飾子をつけることで回避できます*7。

リスト10.33のようなクラスを定義してメソッドを呼び出した場合、IL2CPPで生成されたC++コードではリスト10.34のようなメソッド呼び出しが行われます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public abstract class Animal
{
    public abstract string Speak();
}

public class Cow : Animal
{
    public override string Speak() {
        return "Moo";
    }
}

var cow = new Cow();
// Speakメソッドを呼び出す
Debug.LogFormat("The cow says '{0}'", cow.Speak());

1
2
3
4
5
6
7
8
9
10
11

// var cow = new Cow();
Cow_t1312235562 * L_14 =
    (Cow_t1312235562 *)il2cpp_codegen_object_new(
        Cow_t1312235562_il2cpp_TypeInfo_var);
Cow__ctor_m2285919473(L_14, /*hidden argument*/NULL);
V_4 = L_14;
Cow_t1312235562 * L_16 = V_4;

// cow.Speak()
String_t* L_17 = VirtFuncInvoker0< String_t* >::Invoke(
    4 /* System.String AssemblyCSharp.Cow::Speak() */, L_16);

リスト10.34に示すように、virtualなメソッド呼び出しではないにもかかわらずVirtFuncInvoker0< String_t* >::Invokeを呼び出しており、virtualメソッドのようなメソッド呼び出しが行われていることが確認できます。

一方で、リスト10.33のCowクラスをリスト10.35に示すようにsealed修飾子を用いて定義すると、リスト10.36のようなC++コードが生成されます。

1
2
3
4
5
6
7
8
9
10

public sealed class Cow : Animal
{
    public override string Speak() {
        return "Moo";
    }
}

var cow = new Cow();
// Speakメソッドを呼び出す
Debug.LogFormat("The cow says '{0}'", cow.Speak());

1
2
3
4
5
6
7
8
9
10

// var cow = new Cow();
Cow_t1312235562 * L_14 =
    (Cow_t1312235562 *)il2cpp_codegen_object_new(
        Cow_t1312235562_il2cpp_TypeInfo_var);
Cow__ctor_m2285919473(L_14, /*hidden argument*/NULL);
V_4 = L_14;
Cow_t1312235562 * L_16 = V_4;

// cow.Speak()
String_t* L_17 = Cow_Speak_m1607867742(L_16, /*hidden argument*/NULL);

このように、メソッド呼び出しがCow_Speak_m1607867742を呼び出しており、直接メソッドを呼び出していることが確認できます。

ただし、比較的最近のUnityでは、このような最適化では一部自動で行われていることをUnity公式で明言しています*8。

つまり、sealedを明示的に指定しない場合でも、このような最適化が自動で行われている可能性があります。

しかし、「[il2cpp] Is `sealed` Not Worked As Said Anymore In Unity 2018.3?」\footnotemark[8]というフォーラムで言及している通り、2019年4月の段階で、この実装は完全というわけではありません。

このような現状から、IL2CPPの生成するコードを確認しながら、プロジェクトごとにsealed修飾子の設定を決めるとよいでしょう。

より確実に直接的なメソッド呼び出しを行うために、また、今後のIL2CPPの最適化を期待して、最適化可能なマークとしてsealed修飾子を設定するのもよいかもしれません。

10.9　インライン化による最適化

メソッド呼び出しには多少のコストがかかります。そのため、C#に限らず一般的な最適化として、比較的小さいメソッドの呼び出しは、コンパイラなどによってインライン化という最適化が行われます。

具体的には、リスト10.37のようなコードに対して、インライン化によってリスト10.38のようなコードが生成されます。

1
2
3
4
5
6
7
8
9
10

int F(int a, int b, int c)
{
    var d = Add(a, b);
    var e = Add(b, c);
    var f = Add(d, e);

    return f;
}

int Add(int a, int b) => a + b;

1
2
3
4
5
6
7
8

int F(int a, int b, int c)
{
    var d = a + b;
    var e = b + c;
    var f = d + e;

    return f;
}

インライン化はリスト10.38のように、リスト10.37のFuncメソッド内でのAddメソッドの呼び出しを、メソッド内の内容をコピーして展開することで行われます。

IL2CPPでは、コード生成時にはとくにインライン化による最適化は行われません。

しかし、Unity 2020.2からメソッドにMethodImpl属性を指定し、そのパラメーターにMethodOptions.AggressiveInliningを指定することで、生成されるC++コードの対応する関数にinline指定子が付与されるようになりました。つまり、C++のコードレベルでのインライン化が行えるようになりました。

インライン化のメリットは、メソッド呼び出しのコストが削減されるだけでなく、メソッド呼び出し時に指定した引数のコピーも省けることです。

たとえば算術系のメソッドは、Vector3やMatrixのような、比較的サイズの大きい構造体を複数個引数に取ります。構造体はそのまま引数として渡すと、すべて値渡しとしてコピーされてメソッドに渡されるため、引数の個数や渡す構造体のサイズが大きいと、メソッド呼び出しと引数のコピーでかなりの処理コストがかかる可能性があります。また、物理演算やアニメーションの実装など、定期処理などで利用されることが多いため、メソッド呼び出しが処理負荷として見逃せないケースになることがあります。

このようなケースでは、インライン化による最適化は有効です。実際に、Unityの新しい算術系ライブラリであるUnity.Mathmaticsでは、いたるメソッド呼び出しにMethodOptions.AggressiveInliningが指定されています*9。

一方で、インライン化はメソッド内の処理を展開する処理のため、展開した分コードサイズが増大するというデメリットがあります。

そのため、とくに1フレームで頻繁に呼び出されホットパスとなるようなメソッドに対して、インライン化を検討するとよいでしょう。また、属性を指定すると必ずインライン化が行われるわけではない点にも注意が必要です。

インライン化されるメソッドは、その中身が小さいものに限定されるため、インライン化を行いたいメソッドは処理を小さく保つ必要があります。

また、Unity 2020.2以前では属性指定に対してinline指定子がつかないのと、C++のinline指定子を指定してもインライン化が確実に行われる保証はありません。

そのため確実にインライン化を行いたい場合、可読性は落ちますがホットパスとなるメソッドは手動でのインライン化も検討するとよいでしょう。