有时候感觉 rust 编译挺慢的,是不是因为在 llvm 前端加料太多呢。。。

2022-04-09 14:45:04 +08:00
 alexsunxl

cpu 比较一般 AMD 3600

2842 次点击
所在节点    Rust
5 条回复
mxT52CRuqR6o5
2022-04-09 14:49:19 +08:00
rust 不是号称抽象 0 运行时消耗嘛,不在运行时消耗当然就是在编译时消耗啦
Buges
2022-04-09 16:06:29 +08:00
https://fasterthanli.me/articles/why-is-my-rust-build-so-slow
llvm 本身就挺慢的,再加上链接、宏展开等。rust 是永远选择运行速度(牺牲编译速度)的设计理念。这一点和 go 完全不同。
Kilerd
2022-04-09 18:02:46 +08:00
楼上说得其实都不对,swift 也是基于 llvm 的,怎么没见 swift 编译慢呢?
在 rust 1.60 的更新里面 cargo 支持了一个 timing 的参数来导出编译时间分析 https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html#cargo---timings

业界普遍对 rust 编译慢的认识主要有几点。
1. 真泛型的 monomorphization (不知道怎么翻译这个),倒是了拆解 generic 后的 code bloat 问题,代码技术一下子变得很大。
2. rust 自身几乎不做任何优化的产生 llir ,几乎所有的优化都基于 llvm 自己来做处理,这就是为什么同样基于 llvm 的 swift 不会有这样的问题。
3. rust 在产生 llir 之前经历了 HIR MIR LIR 的阶段,parse 分析等,尤其是 NLL 等特性加入导致其实对于 lifetime ,ownership 的分析会变得很重(具体可以看看 timing 的分析),https://github.com/rust-lang/polonius 基于代数的新型分析器可能能解决这个问题。
4. 如果真是 llvm 的问题,你可以完全切到 cranelift 去试试编译看,其实提升也没有很大就是了。
alexsunxl
2022-04-14 11:29:23 +08:00
@Kilerd 这个参数不错!
alexsunxl
2022-04-14 11:37:55 +08:00
@Kilerd 兄弟。 加个微信聊聊呀。都是深圳的。
我以前前端的。现在搞 rust 搞了小半年。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/845884

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX