回答

ゼロコスト抽象はRustの重要なアイデアであり、抽象（例えば、ジェネリック型、イテレータ、トレイト）が手動で書いた同等のコードと比較して、時間やメモリのコストをかけてはいけないというものです。つまり、高水準のコードは最適化後、低水準のものと同じように効率的にコンパイルされます。

Rustは、モノモーフィゼーションのメカニズムによってこれを実現します：ジェネリックコードは個々の型ごとにコンパイルされ、動的呼び出しはありません。トレイト/ジェネリックで書かれたイテレータやクロージャは、最適化後にコンパイラによって直接の厳密に型付けされたコードに展開され、余分なラッパーは削除されます。

ゼロコストイテレータの例：

let v = vec![1,2,3];
let sum: i32 = v.iter().map(|x| x * 2).sum();

このフラグメントは最適化後にコンパイラによってほぼ手動のループに変換されます：

let mut sum = 0;
for x in &v {
    sum += x * 2;
}

騙しの質問

Rustではゼロコスト抽象がある場合、トレイトオブジェクト（例えば、&dyn Trait）を使用するときにランタイムオーバーヘッドは発生しませんか？

回答：いいえ！ ランタイムオーバーヘッドはvtableを介して動的メソッド選択が行われるときに発生します — dyn Traitを使用する代わりにジェネリック関数を使用する場合に限ります。ゼロコストは静的（モノモーフィズされた）ジェネリック抽象でのみ得られます。

例：

trait Speaker { fn speak(&self); }
fn say_twice<T: Speaker>(v: T) { v.speak(); v.speak(); }
fn say_twice_dyn(v: &dyn Speaker) { v.speak(); v.speak(); }
// 最初の呼び出しはモノモーフィズされ、2番目はvtableを介して行われます

このトピックの詳細を知らないことによる実際のエラーの例

---

物語

パフォーマンスが重要なプロジェクトで、多くの&dyn Traitを使用してジェネリックの代わりに使用した結果、追加の間接呼び出し（vtable経由の呼び出し）により速度が20％低下しました。ジェネリックと静的ディスパッチに書き直したところ、すべてが速くなりました。

物語

Iteratorとmap/filterの型を使用して大規模なデータセットを扱い、コストのかかる探索が発生すると考えていました。アセンブラを分析した結果、最適化後にすべてのチェーンが単純なループに変換され、パフォーマンスが損なわれなかったことがわかりました。つまり、ゼロコストは本当に機能します！

物語

外部ライブラリで、Box<dyn Trait>として返すジェネリック構造体を作成しました。ジェネリック実装にもかかわらず、抽象化がランタイムに移行したため、ゼロコストを失いました。