if
を高速または低速に する主な問題は、予測可能性です。
最新の CPU (2000 年以降のもの) は、分岐予測と呼ばれるメカニズムを使用します。
最初に上記のリンクを読んでから、以下を読んでください...
どちらが速いですか?CPU は if 部分に従うかスキップするかを決定する必要があるため、ステートメントは分岐を構成します
。
分岐を正しく推測すると、ジャンプは 0 または 1 サイクル (1Ghz コンピューターでは 1 ナノ秒) で実行されます。
分岐を正しく推測しない場合、ジャンプには 50 サイクル (ギブまたはテイク) (マイクロ秒の 1/200) かかります。 if
したがって、人間としてこれらの違いを感じるだけでも、if ステートメントを何百万回も実行する必要があります。
上記の 2 つのステートメントは、次の理由により、まったく同じ時間で実行される可能性があります。
- 変数に値を割り当てるのにかかる時間はごくわずかです。平均して、マルチスカラー CPU* で 1 つの CPU サイクル未満です。
- 定数パラメーターを使用して関数を呼び出すには、非表示の一時変数を使用する必要があります。したがって、おそらくコード A は、コード B とほぼ同じオブジェクト コードにコンパイルされます。
*) 現在のすべての CPU はマルチスカラーです。
上記のように、どちらのバージョンもブール値を変数に入れる必要があります。
バージョン A は、あなたが宣言した明示的なものを使用します。バージョン B は、コンパイラによって宣言された暗黙的なものを使用します。
ただし、バージョン A では、関数への呼び出しが 1 つだけであることが保証されていますWriteLine
。
一方、バージョン B には関数への呼び出しが 2 つある場合とない場合がありますWriteLine
。
コンパイラのオプティマイザが適切な場合、コード B はコード A に変換されます。そうでない場合は、冗長な呼び出しが残ります。
どれだけ無駄か
呼び出しは、文字列の割り当てに約 10 バイトかかります (Unicode では 1 文字あたり 2 バイト)。
しかし、他のバージョンもそうなので、同じです。
これにより、呼び出し用に 5 バイトが残ります。さらに、スタックフレームをセットアップするための余分なバイトがいくつかあります。
つまり、まったくひどいコーディングのために、10 バイトを無駄にしたとしましょう。
あまり心配する必要はありません。
保守性の観点から
コンピューター コードは、機械ではなく人間のために書かれています。
その観点から、コード A は明らかに優れています。true または false の 2 つのオプションから選択するのではなく、20 のオプションを選択することを想像してみてください
。関数は 1 回だけ呼び出します。
別の関数の WriteLine を変更することに決めた場合、2 箇所や 20 箇所ではなく、1 箇所だけ変更する必要があります。
これをスピードアップする方法は?
値が 2 つの場合はほぼ不可能ですが、値が 20 個ある場合はルックアップ テーブルを使用できます。
明らかに、コードが何度も実行されない限り、最適化は価値がありません。