Remix.run Logo
▲ Surac 41 minutes ago

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?

▲jerf 26 minutes ago | parent | next [-]

Doing stuff isn't free. For instance, Go compiles relatively quickly for a modern language, but the biggest reason for that is that it does less stuff than most compilers... less optimization, less checking, and some stuff built into the language to avoid some of the problems with having to read lots of headers just to compile a file and other ways of doing less stuff, but mostly the key is it does less stuff, in both the good and bad senses of that.

If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.

And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.

▲ch4s3 24 minutes ago | parent | next [-]

Yeah doing optimizations in a compiler on things like loops, addition, or string layouts is never free.

▲ModernMech 23 minutes ago | parent | prev [-]

And since you bring up Go and contrast the compile time with Rust, it's been experienced at Google (and also Volvo and other places) that Rust and Go teams are as productive whereas C++ is less than half as productive: https://www.youtube.com/watch?t=27012&v=6mZRWFQRvmw&feature=...

So the focus on Rust compile time is misplaced. It's not a big deal in terms of overall productivity.

▲gpm 3 minutes ago | parent [-]

I don't think that follows - just that compile times aren't the only thing that matters. Maybe rust could be twice as productive as go if compile times went to zero for instance (or maybe not - just disputing that the evidence proves the claim here).

▲thevinter 27 minutes ago | parent | prev | next [-]

First of all, the fact that the article talks about "speeding up" the rust compiler doesn't automatically mean that the compiler is "slow"[0].

Now, is rustc slower than e.g. clang? by how much? why?

Those are different (and complicated) questions. It really depends on what you're compiling, but I'd say rustc can be 1-5x slower (maybe more at times?).

The reasons are many and varied, but in general rust compilation is slower because the compiler is doing way more things compared to C (monomorphization, complex trait resolution + type inference, borrow checker..)

[0]: Also I'd argue that "slow" without a concrete point of reference is a meaningless term in this context.

▲pornel 21 minutes ago | parent | prev | next [-]

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).

▲JMKH42 37 minutes ago | parent | prev | next [-]

Its similar to C++ compilers, there is no one reason. It is a language that tries to optimize a lot, its a big language, it does safety checks, it uses llvm which is a bit slow, its a language that makes use of generics which generate extra code etc etc.

▲ModernMech 28 minutes ago | parent | prev [-]

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

▲dralley 22 minutes ago | parent [-]

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.

▲ModernMech 18 minutes ago | parent [-]

Okay but if you don't use generics and monomorphization, then what explains it?

▲dralley 6 minutes ago | parent [-]

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 large Iterator trait implementation.