V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
alexsunxl
V2EX  ›  Rust

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

  •  
  •   alexsunxl · 2022-04-09 14:45:04 +08:00 · 2775 次点击
    这是一个创建于 720 天前的主题,其中的信息可能已经有所发展或是发生改变。

    cpu 比较一般 AMD 3600

    5 条回复    2022-04-14 11:37:55 +08:00
    mxT52CRuqR6o5
        1
    mxT52CRuqR6o5  
       2022-04-09 14:49:19 +08:00 via Android
    rust 不是号称抽象 0 运行时消耗嘛,不在运行时消耗当然就是在编译时消耗啦
    Buges
        2
    Buges  
       2022-04-09 16:06:29 +08:00 via Android   ❤️ 3
    https://fasterthanli.me/articles/why-is-my-rust-build-so-slow
    llvm 本身就挺慢的,再加上链接、宏展开等。rust 是永远选择运行速度(牺牲编译速度)的设计理念。这一点和 go 完全不同。
    Kilerd
        3
    Kilerd  
       2022-04-09 18:02:46 +08:00   ❤️ 3
    楼上说得其实都不对,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
        4
    alexsunxl  
    OP
       2022-04-14 11:29:23 +08:00
    @Kilerd 这个参数不错!
    alexsunxl
        5
    alexsunxl  
    OP
       2022-04-14 11:37:55 +08:00
    @Kilerd 兄弟。 加个微信聊聊呀。都是深圳的。
    我以前前端的。现在搞 rust 搞了小半年。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2856 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 13:00 · PVG 21:00 · LAX 06:00 · JFK 09:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.