変数の割り当ては、null チェックと比較してコストがかかりますか? たとえば、null を割り当てる前に foo が null でないことを確認する価値はありますか?
if (foo != null) {
foo = null;
}
それとも、これは何も心配していませんか?
変数の割り当ては、null チェックと比較してコストがかかりますか? たとえば、null を割り当てる前に foo が null でないことを確認する価値はありますか?
if (foo != null) {
foo = null;
}
それとも、これは何も心配していませんか?
これはマイクロマイクロ最適化です (そしておそらくコンパイラによって処理されるものです)。ご心配なく。プログラムの実際のアルゴリズムに集中することで、はるかに大きな利益が得られます。
約 97% の確率で、わずかな効率性を忘れる必要があります。時期尚早の最適化は諸悪の根源です。-- ドナルド・クヌース
これは実際には (非常に、非常にわずかに)効率的ではありません。変数の割り当ては、null チェックとほぼ同等であり、追加の分岐が可能です。それが大きな違いを生むというわけではありません。
それとも、これは何も心配していませんか?
了解しました。
私はそれについて心配する必要はありません-それは維持するための余分なコード行です. これは、ボトルネックであるという多くの文書化された証拠がない限り、決して行うべきではない一種のマイクロ最適化です。
まず、マイクロ最適化です。したがって、あまり心配する必要はありません。
しかし、あなたの質問に答えるには、それを 1 行に減らす必要があります。(すべてのコードが行うように、NULL に設定するだけです)。
foo = NULL;
理由としては、
比較は、割り当てよりもはるかにコストのかかる操作です。(比較は比較的多くのアセンブリ命令を消費します。一般に、減算とゼロとの比較、または XOR とゼロとの比較)。割り当てに必要な命令は少なくなります。
適切なコンパイラがあれば、同じコードが生成されます。粗悪なコンパイラを使用している場合、 を使用したコンパイラはif
さらに悪化します。2009 では、変数へのハードウェア割り当ては非常に安価であり、条件分岐は時々高価になることがあります。
foo = null;
if (foo != null)
foo = null;
2 番目のブロック コードを見ると、以前は null でなかった場合にのみ foo 変数を null に設定したかったと思います。最初のコードを見ると、変数 foo を null に設定したかったと思います。とりあえず。
これはあなたが書いた例のせいだと思いますが、結局、この種のマイクロ最適化は混乱を招くだけです (それだけの価値はありません)。
これにより、コードが非常に読みにくくなり、たとえそれが最適化であったとしても、問題を起こす価値はありません。
そして、それは最適化ではありません。最近のほとんどの CPU では、if ステートメントは非常に高価です。
これは、ほとんどまたはまったく影響を与えません。違いを実証するためのベンチマークを作成することさえできないと思います。
実際、null への代入はコードの匂いだと主張する人もいます ( NullAssignment の PMD 検出器を参照してください)。
変数に (宣言の外で) 「null」を代入することは、通常、悪い形式です。代入は、プログラマーがコード内で何が起こっているかを完全に理解していないことを示している場合があります。注: この種の割り当ては、まれに、ガベージ コレクションを促進するのに役立つ場合があります。それがあなたがそれを使用しているものである場合、どうしても、このルールを無視してください:-)
一般に、ガベージ コレクションを促進しようとするものには、個人的には懐疑的です (ほとんどの場合、予期しない結果が得られます)。