‹ BackHN Continuity

Thread

How to speed up the Rust compiler in September 2026

279 points · 171 comments · trickypr

  1. Surac · · focus · HN ↗
    Why is the compiler slow in the first place? I have no rust knowledge, how slow us slow, lets say in comparison to a c compiler?

    What is the performance killer?

    1. pornel · · focus · HN ↗
      Zero-cost abstractions aren't zero cost in compilation time. High-level abstractions translate to a lot of boilerplate that the compiler has to optimize out.

      In unoptimized builds often the linker is the bottleneck. Rust/Cargo can parallelize most of the build, generating tons of code and debug info, but then the poor linker has to consume all of it at once. The object/exe formats were designed in ancient times, so they're hard to build incrementally or in parallel (some linkers are trying).

      1. sigbottle · · focus · HN ↗
        Is there any experimentation with new ABIs? I mean certain linker flags like --f-lto literally hijack the linker protocol to dump an AST into the backend.

        At least for the fully static binary part of rust, there should be some optimizations there w.r.t. compilation. Sure you're not going to interface with shared libraries well but maybe a small experimental feature for fully owned projects? Idk.

        1. pornel · · focus · HN ↗
          Rust already uses MIR-based libraries for LTO, and uses thinLTO by default.

          ABIs won't help automatically. The overhead comes mainly from generics and macros. Cross-crate monomorphic generics and AST macros are impossible to express in an ABI. Turning them into polymorphic usually wouldn't remove the many abstraction layers that need to be peeled off, and only make them cost at runtime too.

          So far MIR optimizations were helpful. Rust can simplify high-level MIR quicker than LLVM can simplify the same code after it's been lowered to lots of low-level instructions.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.