結論: 速度が重要です。
私は自分のコードを調べて、その効率を改善する方法をさらに検討することにしました (たとえミリ秒単位であっても、それは素晴らしいことです)。これらすべてのデータ メンバー、メソッド、役に立たないデータ作成 - 私たちは皆、ガイドラインに従うように教えられてきました。
ループを除く。
コードの可読性を向上させ、ユーザーに役立つため、常にそれらを使用することをお勧めします。ユーザー。頭の中で定義を言った後、このアイデアが頭に浮かびました：
for (int i = 0; i < 100; i++)
{
//whatever code
}
長さがわかっている場合を考えてみましょう。これはコードを 100 回実行しますが、マシンを助けるために省略できる 201 回の操作を行います。コードを 100 回コピーして貼り付け、初期化、条件、および終了を破棄するとどうなるでしょうか。
//Code[0]
//Code[1]
//Code[2]
//...
これはほんの少しですが、それでも...
これは効率狂の常套手段ですか？
これは、ループのアンローリングと呼ばれる一般的な最適化であり、優れたコンパイラが自動的に実行するはずです。コードによっては、多くのコンパイラが実際にループをアンロールしますが、これにも絶対的な上限はありません。
極端な例として、ダフのデバイスに興味があるかもしれません。これにより、上限が可変のループでループ展開を行うことができ、最後の「残り」の繰り返しについて心配する必要はありません。
0 から 200 までループしている場合、ループを 200x 展開しても必ずしもパフォーマンスがそれほど向上するとは限りません。生成するコードの量と、分岐を回避することで得られるパフォーマンスの向上との間にはトレードオフがあります。多くのコードでは、10 を超える展開は一般的ではないと思いますが、その数を裏付ける引用はありません。
今日の最も一般的なデスクトップ ラップトップは x86_64 プロセッサを実行しています。これは、順不同の実行や分岐予測などのクレイジーなことを行うスーパースカラーアーキテクチャです。コンパイラが実行できるすべてのクレイジーなことと、CPU が実行しているすべてのクレイジーなことの間には、このような小さなことを手作業で微調整する必要はあまりありません。
実際には、過度の最適化には注意する必要があります。アプリケーションを高速化するのではなく、実際に減速するのでは-O3なく-O2、コンパイルする多くの実験を実行しました。また、LLVM を使用して一連の実験を実行し、個々の最適化をオンまたはオフにしたときに、同じコード (一般的なコンパイラ ベンチマーク) のパフォーマンスがどのように変化するかをテストしました。セット外のほとんどの最適化では、最適化は役に立ったのと同じくらい頻繁に害を及ぼしました。特定のアプリケーションで最適化をテストして、効果があるかどうかを確認する必要があります。-O2
ただし、通常は、このようなちょっとした最適化ではなく、適切なデータ構造とアルゴリズムを選択することで最大のパフォーマンスが得られます。最適化には次のアプローチを取るのが最善だと思います。