重複の可能性:
「else if」は「switch() case」より速いですか?
Java での if/else と switch ステートメントの相対的なパフォーマンスの違いは何ですか?
case ステートメントはジャンプ テーブルで実装できることを知っています。これにより、if ステートメントよりも効率的になりますか?
これは避けるべき単なるマイクロ最適化ですか?
重複の可能性:
「else if」は「switch() case」より速いですか?
Java での if/else と switch ステートメントの相対的なパフォーマンスの違いは何ですか?
case ステートメントはジャンプ テーブルで実装できることを知っています。これにより、if ステートメントよりも効率的になりますか?
これは避けるべき単なるマイクロ最適化ですか?
主なことは、コードをできるだけ明確に書くことだと思います。このようなマイクロ最適化に焦点を当てるべきではありません。
たとえば、次のようなものがあるとします。
if (age == 10) {
// ...
} else if (age == 20) {
// ...
} else if (age == 30) {
// ...
} else if (age == 40) {
// ...
}
次に、switch ステートメントを使用する方が明確です。
switch (age) {
case 10:
// ...
break;
case 20:
// ...
break;
case 30:
// ...
break;
case 40:
// ...
break;
}
ここでも、ナノ秒レベルの効率向上ではなく、コードを読みやすく、保守しやすいものにすることに重点を置きます。
コンパイラは、値が適度にコンパクトであることを確認できる場合、ジャンプ テーブルを作成します。(この場合、それらが 10 の倍数であるかどうかは疑問です。)
これはマイクロ最適化です。マイクロ最適化は、そうであることがわかっている場合にのみ意味があります。通常、他の場所には、なくても実行できる関数呼び出しの形で、より大きな「揚げ物」があります。ただし、このコードから既に日光を調整しており、プロファイリングでかなりの割合 (10% 以上) の時間がこれらの IF ステートメント (およびその内容ではない) に費やされていることが示されている場合は、それが役立ちます。これは、たとえば、バイトコード インタープリターで発生する可能性があります。
追加: 私が使用したいもう 1 つの理由switch
は、ジャンプ テーブルを作成しない場合でも、デバッガーでコードをステップ実行するときに、多くの誤ったif
ステートメントをステップ実行するのではなく、適切なケースに直接移動することです。デバッグが容易になります。
if else ステートメントの非常に大きなチェーンがある場合は、そうです、違いを感じるかもしれません。しかし、これほど長い ifelse チェーンを記述することは非常に非現実的です。仮にそうしたとしても、それがパフォーマンスのボトルネックになる可能性は非常に低いです。
最初にコードを読みやすいように記述し、パフォーマンスの最適化が必要になったときにプロファイラーに導かれるようにします。
おそらく問題ではありません。バイトコードは、JVMへの単なる「トランスポート形式」です。JVM内で何が起こるかは、バイトコード表現とは大きく異なります。(例:バイトコードはfloat演算を提供しないため、float +-* /%floatはdouble演算として実行され、結果はfloatにキャストバックされます。byte/ shortにも同じことが当てはまり、intに変換されてから元に戻ります。 。)しかし、スイッチの場合、それらは2つのバイトコード形式であり、1つはすでにジャンプテーブルを備えています。しかし正直なところ、私はあなたとあなたのプログラムの読者に最適なフォーマットを選びます。残りはJVMが行います。頭が良すぎると、JVMがポイントを取得できず、最終的にプログラムの速度が低下する可能性があります。
「私たちは小さな効率を忘れるべきです。たとえば、97%の確率で:時期尚早の最適化はすべての悪の根源です」D.クヌース