http://kan-kikuchi.hatenablog.com/entry/Assert
Unityには標準でアサーションクラスが定義されています。
これはdevelopment buildのチェックを外すと製品版から取り除くことができる優れものです。
防御的プログラミングとしてアサーションを積極的に使っていることでしょう。

しかしUnityのこのアサーションクラスを使うときに気をつけなくてはいけないことが、いくつかあります。
それを見ていきましょう。

Assertの第二引数は必ず評価される

どういうことかというと

SpriteRenderer sprite = null;
Assert.IsTrue(true, sprite.name);

このAssertは常に正なのでアサーションは発生しません。
にもかかわらず第二引数であるsprite.nameは評価され、null errorが発生します。
これ、意外と引っかかります。
そのため第二引数部分は、どんな時でも正常に動作するコードのみ書かなくてはいけません。

Assertはラップして使う

次のコードを見てください。

void Update()
{
Assert.IsNotNull(hogehoge, "hogehoge is null =" + Time.frameCount);
}

hogehogeがnullだったらアサーション発生というごく普通のコードです。
ところが第二引数は必ず評価されます。
この処理は動的にstringインスタンスを生成するためgcallocが発生します。
さらにUpdateで毎フレーム呼び出されるため、毎フレームgcallocが発生します。
これが致命的で、無駄なgcallocのせいでパフォーマンスの正確な計測が難しくなります。

development buildのチェックを外すことでアサーションを無効化できますが、今度はprofilerが使えなくなるのでパフォーマンスチェックできません。

PlayerSettingsのLoggingでAssertをNoneにしても呼び出しはされるため結局gcallocされます。対策としては

if文で囲う
自前Assertを作る

UnityのAssertクラスをラップして自プロジェクト用のMyAssertクラスを作ればよいのです
http://d.hatena.ne.jp/nakamura001/20151202/1449029637
[System.Diagnostics.Conditional(“USE_ASSERT”)]　を設定し、USE_ASSERTデファインを無効にすればAssertの呼び出しそのものを無くすことができます。