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中提供官方构建性能优化指南，助开发者理解可行选项与其取舍。
