卡拉今天看了什麼"Why is the Rust compiler so slow?"
LinkWhy is the Rust compiler so slow?https://sharnoff.com/post/why-is-the-rust-compiler-so-slow/
📌 Summary:
本文探討為何 Rust 編譯器在使用 Docker 建置環境中導致網站編譯時間冗長的原因，透過詳細分析和多次嘗試優化，揭示了 Rust 編譯執行效率低的多重因素。作者原本使用 Rust 靜態編譯生成二進位檔並部署，為了符合現代容器化部署流程，嘗試將建置流程容器化，但遇到編譯時間無法有效縮減的問題。最初透過cargo-chef進行依賴快取，減少重複編譯依賴，僅編譯專案本身，雖有改善但最終編譯時間仍然偏長。藉助Rust 的self-profile功能及LLVM的詳細追蹤分析，作者發現編譯時間主要消耗在 Link-Time Optimization (LTO)、LLVM 模組優化和函式內聯過程。嘗試調整release profile中的LTO參數，優化等級和除錯符號配置，並深入LLVM的Pass執行效率，發現收斂編譯時間的策略包括降低inlining的閾值、拆分大型異步函式、將泛型函式去泛型化、束縛future為trait物件等。2025 年 6 月 27 日後續分享也納入-Zshare-generics旗標調優和改用Debian基底映像替代Alpine以提高記憶體分配效率，最終將編譯時間大幅縮短至原本的約五分之一。文章也指出Rust編譯器仍有優化空間，尤其是異步函式的深度呼叫結構和drop函式的重複編譯問題，並呼籲未來可透過工具進一步協助碼農定位和減緩編譯瓶頸。整體來說，本文以實務經驗為核心，系統性剖析及調整Rust編譯流程，對於希望提升Rust大型專案在CI/CD中編譯效率的開發者提供參考與啟發。
🎯 Key Points:
→ Docker中Rust編譯挑戰：原始流程每次更改都完整重建二進位檔，耗時約4分鐘。引入cargo-chef實施依賴快取，僅重編自家code，縮短至約3分鐘，但仍無法達理想。
→ 編譯自我分析工具：運用cargo build --timings及rustc -Zself-profile收集詳細執行時間，定位編譯瓶頸集中於LTO、LLVM模組優化(LLVM_module_optimize)與指令內聯(InlinerPass)等。
→ LTO調整實驗：Rust編譯器預設為thin local LTO，作者嘗試關閉LTO、使用thin及fat LTO比較編譯時間與輸出大小，發現fat LTO耗時最高，關閉LTO可縮至約50秒；同時關閉debug資訊亦有顯著效果。
→ LLVM細節剖析：利用LLVM Pass執行時間報告和chrome tracing格式輸出，發現InlinerPass及OptFunction為耗時最多的Pass。嘗試透過-C llvm-args降低內聯閾值，成功將時間縮短5秒以上。
→ 大型異步函式問題：大型async函式及其內部closure因複雜state machine，導致編譯優化耗時爆增。透過拆分函式、減少泛型化並將Future包裝成Pin<Box<dyn Future>>減緩編譯負擔，從5秒降至約2秒。
→ 泛型與drop_in_place重複編譯：LLVM多次編譯外部依賴中泛型函式的drop_in_place，耗費大量優化時間。啟用-Zshare-generics可共享泛型實例化，進一步縮短優化時間約10%。
→ 基底映像影響編譯速度：由於Alpine使用musl及其預設記憶體配置，影響整體編譯效能；改用Debian基底並避免cross compile大幅縮短編譯時間，從29秒降至9秒。
→ 實務組合優化成果：總結從175秒縮減至9秒的策略包括關閉或調整LTO、降低優化等級、修改內聯策略、函式拆分、泛型共享及改變Docker基底映像。
→ 編輯未來展望與問題：Rust編譯器對大型async函式的優化存在挑戰，重複編譯drop glue過多問題嚴重，呼籲日後可增加special-case處理及開發相關工具協助分析及優化。
🔖 Keywords:
#Rust_Compiler #Docker_Build #LinkTimeOptimization #LLVM_Optimization #async_函式拆分
Habr
sumiyaki