我改进了我的 Rust 编译时间

Rust 编译时间与迭代速度

• 许多人认为 Rust 的构建仍然很慢：即使已经提升了 75%，在一台强劲机器上 4–5 秒的增量编译，在一些人看来仍然过高，尤其是对于小型静态站点。
• 也有人认为 4–5 秒是可以接受的，并强调 Rust 强大的编译期保证的价值，相比之下，JS/TS 中虽然快速但容易出错的热模块重载（HMR）并不可靠。
• 有些人报告说，在普通硬件上项目编译要花几分钟，担心 Rust 实际上需要昂贵的机器，并可能阻碍采用。
• 几位发帖者强调，短的编辑—运行循环（1–2 秒）对生产力影响很大；也有人认为在 Rust 中主要循环是“编辑，等待 rust-analyzer”，因此对完整构建的依赖较低——不过据称 rust-analyzer 在较大的仓库中也很慢。

硬件：CPU vs RAM vs 存储

• 线程中分享的基准测试表明，编译时间与核心数成正比；每次构建超过约 1 GB 的额外内存对典型 crate 并没有帮助，不过内存速度也许有影响。
• 64–128 GB 的高内存机器被认为对 Rust 来说有些过度，但对虚拟机、sanitizer 和本地 LLM 很有用。
• 对 RAM 压力的体验不尽相同：一些 Linux 用户在 32 GB 时就遇到 OOM/硬重启，另一些人则说如果配置得当（swap、zram 等），Linux 的内存使用很高效。原因存在争议，也不太明确。
• 笔记本 RAM 的价格颇具争议；焊死内存和高端品牌会让 32 GB 很贵，但可升级或非高端的笔记本可能更便宜。

工具链：链接器、缓存、后端

• 讨论了 mold/sold：sold 本质上是在商业许可下的 mold；mold 现在采用宽松许可，但仍不支持 macOS。据称 Apple 新的并行化链接器已经快到足以让 sold 基本过时。
• 作为替代后端的 Cranelift 可以加快构建（有传闻称可提升 20–30%），但一些人认为相对于整体慢的问题，这样的收益仍然有限。
• 建议包括使用 sccache 和 firebuild；firebuild 可以缓存链接和构建脚本，并声称在某些 Rust 构建中可带来超过 90% 的加速（Mac 支持仍处于实验阶段）。
• cargo-leptos 的 separate-front-target-dir 设置现在始终启用，并已作为用户选项弃用。

语言与编译器设计权衡

• 多条评论指出，借用检查器对编译时间的贡献很小；主要元凶是单态化和宏展开，它们会生成大量 LLVM 工作负载，但也带来了更快的运行时代码。
• Rust 的编译单元是 crate（允许 crate 内部的循环依赖），这限制了并行度；相比之下，C/C++ 中每个源文件都是一个编译单元。
• 有人认为 Rust 是把工作前置（严格类型、所有权）以减少运行时调试；也有人反驳说，在看到行为之前就过度投入类型设计可能浪费时间，而快速的运行时迭代仍然至关重要。
• 观察者指出，编译器提速工作已经持续多年，但改进是渐进的；如今性能分析曲线已经“变平”，说明大多数容易拿到的收益已经没有了，进一步的大幅提升可能需要深层的架构变更。

前端工作流与模板

• 前端开发者讨论 Rust 是否适合快速 UI 迭代：长时间重建被认为无法接受，尤其是对快速修改 CSS/标记的场景。
• 也有人反驳说，Rust 的安全性“值得等待”，尤其是与许多错误只会在运行时才暴露的旧式 JS 相比。
• 有评论者质疑为什么 HTML 模板的修改会触发完整的 Rust 重建，建议使用外部模板，或者采用不需要重新编译的设计；不过文章中的具体设置并不清楚。

其他讨论点

• 有些人希望文章能明确提到 sccache。
• 也有人好奇是否有专门针对 Rust 编译的 CPU 基准测试；phoronix/openbenchmarking 被提及为相关来源。
• 博客上使用 AI 生成的封面图被广泛批评为分散注意力且通常未披露；几位评论者承认自己停下来检查这些瑕疵，而不是继续读正文。