Backendに.NETを指定すると「将来的に.NETはサポートされなくなり、IL2CPPが標準になります。」といった内容の警告が表示されるようになります。実際,いくつかのUnityの標準APIが.NET環境だとビルドできず,IL2CPPのみのサポートになったりしています。2018.3現時点ではサポート対応が続いているも,2019でどうなるかはまだわかりません。Unity2018で.NETを選択した際の警告この将来的な変更に対する議論がこちらでなされていました。参考になったのでここのリンクベースで説明していきます。fast?この変更に対する公式の意見があるので英語大丈夫という方はこちらを読んでください。問題点について先に触れます。Unityからのビルド後にソースコードの変更が加えられなくなった点。IL2CPPでは,UWPのプロジェクトを吐き出しはしますが,その中身はマネージドアセンブリをC++に変換したものです。このおかげでJITコンパイルに比べて一般的にパフォーマンスがでるといった恩恵を受けられる訳ですが,マシンによって変換されたコードはとても人の手に負えるものではありません(できる人はできるんだろうけど)。プラットフォーム依存の処理の部分の書き分けも問題になります。WINDOWS_UWPなどで囲まれたディレクティブ内ではインテリセンスが効かないため,タイプミスといったエラーが頻発します。NETではUWPのC#プロジェクトとして出力できるため,Unityからビルド後にプラットフォーム依存の部分を別で開いたVSから書くといったやり方ができました。最終的にはIL2CPPを使いたいけど,変更の容易性や時間といった問題から,.NETで作業してからIL2CPPでビルドし直すという人もいるでしょう。defineディレクティブを使った処理の書き分けIL2CPPでは先のリンクの方が質問で投げているように,.NETの数十倍近いコンパイル時間がかかります。これは,.NETアセンブリから使われていない部分をstripping(=除去)して,C++に変換するプロセスがあるため当然その分遅くなります。細かいコード修正で都度Unityからビルドするのは効率は悪いですし,やっている方も辛いでしょう(実際つらい)2017.4の空プロジェクトの場合だと,あまり大きな違いがないようには見えますがプロジェクトの規模が大きくなってくるほどこの差は大きく開いていきます。有効にする実はIL2CPPにスイッチングした状態でVSを立ち上げると,通常のプロジェクトに加えて.Playerというネイティブコードを記述できるプロジェクトが自動作成されます。Editor用のプロジェクトと、.Playerはスクリプトのみに関し同じ構造をとっています。それぞれのスクリプトを切り替えることで、ネイティブコード、それ以外などをインテリセンスが有効な状態で記述できます。マニュアルビルド時間の短縮ビルド時間の短縮については,公式のマニュアルにも案内が出ています。コンパイラーは、最後にコンパイルしてから変更が加えられたファイルのみを再度コンパイルします。以前のビルドロケーションと同じ場所にプロジェクトをビルドします。先ほどの計測で,突っ込んでいなかった部分です。2回目のビルド時間が大幅に短縮していた理由がこれです。個人的な感想で言えば,プロジェクト規模が大きくなってくるとあまり効果を感じにくくはなりますね。プロジェクトとビルドフォルダーをマルウェア対策のソフトウェアスキャンから除外プロジェクトをビルドする前に、マルウェア対策のソフトウェアを無効にしてビルド時間を向上させることができます。ビルド時間が減少しました。)フルで切るわけにはいかないので,今回はプロジェクトフォルダがある場所をDefenderの対象から外します。除外の項の「除外の追加または削除」から除外を追加します。この状態での計測結果です。確かに50%近くまでビルド時間が減りました。比べ、より速く読み込み、書き込みを行えます。変換しそれをコンパイルすることは、大量の読み込み、書き込み操作を伴います。ストレージデバイスのスピードが速いと、この処理もより早くなります。これに関しては特に突っ込みません。