一般的なヒント

本書のこれまでのセクションでは、Rust 固有のテクニックについて説明してきました。 このセクションでは、一般的なパフォーマンス原則の概要を簡単に説明します。

明らかな落とし穴（例: 非リリースビルドを使用する）を避けている限り、 Rust コードは一般に高速で、メモリ使用量も少なくなります。特に、Python や Ruby のような 動的型付け言語、あるいは Java や C# のようなガベージコレクターを備えた 静的型付け言語に慣れている場合はそう感じるでしょう。

最適化されたコードは、最適化されていないコードよりも複雑で、書くのに手間がかかることがよくあります。 このため、最適化する価値があるのはホットなコードだけです。

最大のパフォーマンス改善は、低レベルの最適化ではなく、アルゴリズムや データ構造の変更によってもたらされることがよくあります。 例 1, 例 2.

現代のハードウェアとうまく連携するコードを書くことは、必ずしも簡単ではありませんが、 取り組む価値があります。たとえば、可能な場合はキャッシュミスや分岐予測ミスを 最小限に抑えるようにしてください。

ほとんどの最適化は小さな速度向上をもたらします。個々の小さな速度向上は 目に見えるものではありませんが、十分な数を積み重ねることができれば、大きな効果になります。

プロファイラーによって得意分野は異なります。複数を使用するのがよいでしょう。

プロファイリングによって関数がホットであることが示された場合、速度を上げる一般的な方法は 2 つあります: (a) その関数を高速化する、および/または (b) その関数の呼び出し回数を できるだけ減らす、です。

巧妙な速度向上を導入するよりも、ばかげた速度低下を取り除くほうが簡単なことがよくあります。

必要でない限り、計算を避けてください。遅延/オンデマンドの計算は 多くの場合、有利に働きます。 例 1, 例 2.

複雑な一般ケースは、より単純な一般的な特殊ケースを楽観的にチェックすることで 避けられることがよくあります。 例 1, 例 2, 例 3. 特に、小さいサイズが支配的な場合、0、1、または 2 個の要素を持つコレクションを 特別に扱うことは有利に働くことがよくあります。 例 1, 例 2, 例 3, 例 4.

同様に、反復的なデータを扱う場合、一般的な値にはコンパクトな表現を使用し、 通常とは異なる値にはセカンダリテーブルへフォールバックすることで、単純な形式の データ圧縮を使用できることがよくあります。 例 1, 例 2, 例 3.

コードが複数のケースを扱う場合は、ケースの頻度を測定し、最も一般的なものを最初に処理してください。

局所性の高い検索を扱う場合、データ構造の前段に小さなキャッシュを置くことが 有利に働くことがあります。

最適化されたコードは、構造が明らかでないことがよくあります。つまり、説明コメントには価値があり、 特にプロファイリング測定値を参照するコメントは有用です。「このベクターは 99% の時間で 0 個または 1 個の要素を持つため、それらのケースを先に処理する」といったコメントは、 理解を助けるものになり得ます。