Rust編譯效能調查出爐，近半數停用者點名編譯時間過久

Rust官方首次進行編譯器效能調查，整體滿意度平均為6分，最常見評分為7分，但開發者體驗差異明顯，在已不再使用Rust的受訪者中，約45％指出編譯時間過久是停用的重要原因之一。官方也針對多數痛點提出短中長期的改善方向。

調查結果顯示，增量重建是最常見的抱怨來源。受訪者在被要求挑出經手編譯時間最吃力的專案時，有55％抱怨，程式碼小幅修改後需要等待超過10秒才能重建。

Rust官方解釋，增量重建延遲主要有3個原因，分別是工作空間內改動會觸發相依Crate重建，導致不必要的編譯，第2是連結階段無法增量化，每次都需從頭開始，第3則是單一Crate的增量引擎仍有最佳化空間，例如derive程式碼產生器的展開尚未快取。官方預計在下一個版本，就會把Linux上最常用的x86_64-unknown-linux-gnu目標預設連結器切換為LLD，以縮短連結時間。

在型別檢查與IDE效能上，調查顯示工具協作仍有落差，約6成開發者習慣用Cargo指令檢查或建置，其中cargo check最常被使用，但由於與cargo build不共享快取，常導致重複編譯，增加額外等待時間。雖然大多數人仰賴編輯器內的即時註解來快速查看錯誤，但仍有約3成受訪者反映延遲過久影響開發流程，另有超過35％指出IDE與Cargo會互相阻塞，造成體驗中斷。

Rust Analyzer已透過PGO最佳化提升約15％至20％效能，藉以改善這些問題，並持續改進快取與整合新版trait解析器（Solver）。官方同時建議，若將Rust Analyzer與Cargo設定使用不同目錄，可減少相互等待的情況，雖然會增加磁碟用量。

調查顯示除錯資訊的生成也會拖慢建置速度，要是僅保留行級資訊，效能可提升達2至3成，但不同開發者對除錯需求差異大。Cargo團隊因此評估調整預設層級，並規畫提供更適合除錯的檔案集，以兼顧效能與開發便利。

在實務經驗中，受訪者最常提及的改善方式包括減少相依函式庫、拆分大型Crate，以及改用更快的連結器，如LLD或mold。官方則回應，這些措施屬於折衷方案，成效雖佳，但可能帶來維護或效能上的額外成本，因此未來將在Cargo Book中提供官方建置效能最佳化指南，助開發者理解可行選項與其取捨。