2025/07/04 20:11 How much code does that proc macro generate?
やっほー、ロボ子！Rustのproc macroに関する面白いニュースを見つけたのじゃ。
博士、こんにちは。proc macroですか。少し扱いにくいイメージがあります。
そうそう、proc macroは強力だけど、コンパイル時のコストが気になるのじゃ。そこで、新しいツール`-Zmacro-stats`が登場したみたい。
`Zmacro-stats`ですか？それは一体何をするんですか？
これはね、proc macroが生成するコードのサイズを定量化してくれるツールなのじゃ。これを使えば、どのmacroがどれだけコードを生成しているか一目瞭然！
なるほど、コードサイズを把握することで、コンパイル時間のボトルネックを見つけやすくなるんですね。
その通り！記事によると、proc macroのコンパイル時間には、macroクレート自体のコンパイル時間、依存クレートのコンパイル時間、macroの実行時間、そして生成されたコードのコンパイル時間が影響するらしいのじゃ。
結構色々な要素が絡み合っているんですね。`watt`というアプローチでコストを回避できるとありますが、これはどういうものですか？
`watt`はね、proc macroクレート自体のコンパイル時間と、依存クレートのコンパイル時間を回避するアプローチなのじゃ。でも、今回は`-Zmacro-stats`の話に集中するのじゃ！
わかりました。記事には、大規模プロジェクトではmacro展開後にコードサイズが3倍以上になることがあると書かれていますね。それは恐ろしいです。
じゃろ？`-Zmacro-stats`の出力例も載っていて、`println!`は1回の使用で1行のコードを生成するらしいのじゃ。`serde::Deserialize`は159行も生成するみたい。
`serde::Deserialize`はそんなに多くのコードを生成するんですね。驚きです。もしコンパイル時間が気になる場合は、`serde-lite`や`miniserde`を検討するのも良いと。
そうそう！記事にも「proc macroの使用を避けるか、より安価な代替手段を見つけることが解決策となる場合がある」って書いてあるのじゃ。
`-Zmacro-stats`は、コードベースに多数のderiveがある場合に特に有用とのことですね。
その通り！でも、コード行数はあくまで指標の一つで、コンパイル時間そのものが最も重要な測定値なのじゃ。
勉強になります。私も`-Zmacro-stats`を使って、自分のプロジェクトのmacroを分析してみようと思います。
それは良い心がけじゃ！…ところでロボ子、macroがたくさんあるコードって、まるで迷路みたいじゃな？
そうですね、複雑に入り組んでいることがありますね。
ふふ、迷路といえば…maze（メイズ）るほどコンパイルが終わらない、なんてね！
あはは…博士、それ、ちょっと強引すぎます。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。