1

長さ - 1 までカウントアップするのではなく、長さ - 1 からゼロまで小さなループで (可能な場合) カウントすることをお勧めしますか?

1.) カウントダウン

for (int i = a.length - 1; i >= 0; i--) {
    if (a[i] == key) return i;
}

2.) カウントアップ

for (int i = 0; i < a.length; i++) {
    if (a[i] == key) return i;
}

最初のものは2番目のものよりもわずかに高速ですが（ゼロと比較する方が速いため）、私の意見ではエラーが発生しやすくなっています。さらに、最初のものは、JVM の将来の改善によって最適化されない可能性があります。それに関するアイデアはありますか？

4

6 に答える 6

11

a.length の結果を変数に格納すると、実際にそうであったとしても「速く」なりません。いずれにせよ、このような些細な操作のパフォーマンスについて心配する価値はほとんどありません。メソッドの可読性に注目してください。

私にとっては、カウントアップの方が読みやすいです。

于 2010-03-23T23:08:50.833 に答える
4

私の意見では、プリエンプティブな最適化よりも慣習と可読性 (この場合はカウントアップ アプローチ) を優先する方がはるかに優れています。Josh Bloch によると、最適化が必要であると確信できるまでは、コードを最適化しない方がよいとのことです。

于 2010-03-23T23:11:11.927 に答える
1

このような多くの変更を行う前に、これがパフォーマンスの問題であることを示すベンチマークがあることを確認することをお勧めします。私はいつでも最も読みやすいものを選びます（私の意見では、それが上に数えられるものです）。

マイクロ最適化に興味があり、コンパイラが正しいことを行うとは信じていない場合は、間接化を回避するために、2 番目のループの変数に a.length をキャッシュすることを検討する必要があります。

于 2010-03-23T23:08:07.610 に答える
0

「私たちは小さな効率性を忘れるべきです。たとえば、約 97% の時間です。時期尚早の最適化はすべての悪の根源です」、Donald Knuth.

この場合、読みやすさの損失だけがパフォーマンスの向上を上回ると私は主張します。プログラマーの時間は、CPU 時間よりもはるかに高価です。

PS: パフォーマンスをさらに向上させるには、ゼロに対する不等式のテストを検討する必要があります。ただし、空の配列に注意してください ;)

于 2010-03-24T15:52:48.960 に答える
0

ある方法と別の方法（リスト内の項目の順序など）を数える理由がある場合は、慣例に従って行こうとして結び目をひねらないでください（経験から、数え上げます）。そうでない場合は、次の人が作業しやすくし、慣習に従います。

0 との比較と int との比較は、特に問題になることはありません...

于 2010-03-23T23:31:47.130 に答える