この記事は【unityプロ技②】 Advent Calendar 2019の14日目の記事です。

記事に登場するコードはパブリックドメインです

#NestedPrefabは爆速である？

Unity2018.3より前から開発していたプロジェクトにおけるフィールドデータで、現在のNestedPrefabのようにプレハブを入れ子にした場合でも子プレハブ側の変更が反映されるようにしたいことがありました。

これを実現するため、プレハブ内には仮オブジェクトを置いておき、実行時にプレハブから生成したものに差し替えるようにしていました。

これをNestedPrefabに移行した際に強く感じたのが シーンのロードが爆速になった！！ ということです。

NestedPrefab is 爆速？ 今回はこの仮説をエディタ上で簡単に検証してみました。

#確認環境

macOS High Sierra 10.13
プロセッサ 2.6 GHz Intel Core i7 クアッド
メモリ 8 GB 1600 MHz DDR3
Unity2019.2.13f1

#Instantiate vs Nested

まず実行時に生成するパターンですが、以下のようにSerializeFieldに設定したプレハブからInstantiateします。

[SerializeField] private GameObject[] prefabs = null;

void Awake()
{
    var t = transform; 
    for (int i = 0; i < prefabs.Length; ++i)
    {
        Instantiate(prefabs[i], t);
    }
}

Nestedのほうは直接プレハブの中に入れます。Instantiateのほうでは子プレハブをInstantiateするためのスクリプトを付けていることやAwake()がコールされることのオーバヘッドで速度差が出るかもしれないので、空のAwakeだけ実装したスクリプトをルートに貼り付けておきました。

どちらもプレハブのロードにはResources.Load()を使用します。また、生成が1個だけだとすぐ終わってしまうので同じプレハブを100個生成します。この条件での検証結果は以下の通りです。

	Serialize & Instantiate	Nested
Resources.Load()	2ms	2ms
100個生成	13〜14ms	7〜8ms

ロード時間に差はなしでしたが、生成は40%ほど早くなっていました。

Instantiateを使用することによるオーバヘッドを考えれば想像がつくことではありましたが、やはり実測値としてもNestedPrefabを利用することで高速化が見込めることは間違いなさそうです。

ここでは子プレハブを参照するのにSerializeFieldを使用していますが、子プレハブもそれぞれResources.Load()でロードしてくるようなケースではロード時間にも大きな差が出るでしょう。AssetBundleなら尚更です。

#Nested vs Unpack

ついでに子プレハブを全てUnpackして1つのプレハブに統合した場合との比較も行いました。

	Nested	Unpack
Resources.Load()	2ms	2ms
100個生成	7〜8ms	7〜8ms

こちらは特に差は出ませんでした。どちらの場合でも内部で最大限に最適化されていることが予想できます。

#まとめ
今回の検証ではNestedしているプレハブは5個だけでしたが、僕が爆速になったと体感したフィールドデータはもっと大量のオブジェクトが入っていたので規模が大きくなればなるほどNestedPrefabの恩恵も大きくなるでしょう。

NestedPrefabを含めプレハブのワークフローが改善されたことで利便性がとても向上しましたが、同時にパフォーマンス最適化の面でも活用の幅が広がったように思います。