Thread

1. Surac · 1790861317 · 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. ModernMech · 1790862095 · focus · HN ↗

      It's doing static analysis that many other languages don't do at compile time.

      1. dralley · 1790862496 · focus · HN ↗

         This is not actually the main reason, most of the time.

         Generics/monomorphization and how iterators work results in a lot of compiler bytecode that has to be churned through. More bytecode = longer compilation. It increases the size of the (debug) binaries, the debuginfo in general, causes performance issues with debug binaries in some situations unless you bump the optimization level, causes more IO, etc.

         1. ModernMech · 1790862709 · focus · HN ↗

            If you don't use generics and monomorphization, then what explains it?

            1. dralley · 1790863428 · focus · HN ↗

               It's unlikely that many people are using Rust without using Option<T> or Result<T, U> a fair bit. Idiomatic Rust fundamentally uses a lot of generics. And a basic for loop expands into quite a lot of intermediate representation due to Iterator.

               1. ModernMech · 1790865114 · focus · HN ↗

                  Other languages support generics, monomorphization, and iterators (e.g. Zig or D), but they're not as slow as Rust to compile, what's the reason for that?

                  1. moritzruth · 1790865594 · focus · HN ↗

                     AFAIK it's because of trait solving. And also not every language does monomorphization.

                     1. kibwen · 1790868210 · focus · HN ↗

                        Trait solving isn't a bottleneck for Rust compilation unless you're doing some extremely cursed things like trying to implement Doom in the type system. At the end of the day it's still mostly that Rust just generates a ton of IR for LLVM to chew on (because of monomorphization), then LLVM takes a while to process all of it (because LLVM is designed primarily to produce high-performance code, often resulting in reasonable tradeoffs against compilation speed), and then the linker takes a while to connect it all together. With an alternative backend to LLVM (e.g. Cranelift) you could choose to design it with a greater emphasis on compilation speed (likely trading off generated code quality in the process). And with a more radical vertically-integrated model where Rust controls the linker you could do in-place linking and nearly completely skip the final step (at least for debug builds), but that's a big change compared to the classic C-style build model.

Unofficial Hacker News client; not affiliated with Y Combinator.