←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 3 comments | 26 Jun 25 19:29 UTC | HN request time: 0.702s | source
Show context
taylorallred ◴[26 Jun 25 20:29 UTC] No.44390996[source]▶
So there's this guy you may have heard of called Ryan Fleury who makes the RAD debugger for Epic. The whole thing is made with 278k lines of C and is built as a unity build (all the code is included into one file that is compiled as a single translation unit). On a decent windows machine it takes 1.5 seconds to do a clean compile. This seems like a clear case-study that compilation can be incredibly fast and makes me wonder why other languages like Rust and Swift can't just do something similar to achieve similar speeds.
replies(18): >>44391046 #>>44391066 #>>44391100 #>>44391170 #>>44391214 #>>44391359 #>>44391671 #>>44391740 #>>44393057 #>>44393294 #>>44393629 #>>44394710 #>>44395044 #>>44395135 #>>44395226 #>>44395485 #>>44396044 #>>44401496 #
dhosek ◴[26 Jun 25 20:46 UTC] No.44391170[source]▶
Because Russt and Swift are doing much more work than a C compiler would? The analysis necessary for the borrow checker is not free, likewise with a lot of other compile-time checks in both languages. C can be fast because it effectively does no compile-time checking of things beyond basic syntax so you can call foo(char) with foo(int) and other unholy things.
replies(5): >>44391210 #>>44391240 #>>44391254 #>>44391268 #>>44391426 #
Thiez ◴[26 Jun 25 20:56 UTC] No.44391268[source]▶
This explanation gets repeated over and over again in discussions about the speed of the Rust compiler, but apart from rare pathological cases, the majority of time in a release build is not spent doing compile-time checks, but in LLVM. Rust has zero-cost abstractions, but the zero-cost refers to runtime, sadly there's a lot of junk generated at compile-time that LLVM has to work to remove. Which is does, very well, but at cost of slower compilation.
replies(1): >>44391818 #
vbezhenar ◴[26 Jun 25 21:47 UTC] No.44391818[source]▶
Is it possible to generate less junk? Sounds like compiler developers took a shortcuts, which could be improved over time.
replies(3): >>44392001 #>>44392115 #>>44394849 #
zozbot234 ◴[26 Jun 25 22:29 UTC] No.44392115[source]▶
You can address the junk problem manually by having generic functions delegate as much of their work as possible to non-generic or "less" generic functions (Where a "less" generic function is one that depends only on a known subset of type traits, such as size or alignment. Then delegating can help the compiler generate fewer redundant copies of your code, even if it can't avoid code monomorphization altogether.)
replies(1): >>44394609 #
andrepd ◴[27 Jun 25 07:41 UTC] No.44394609[source]▶
Isn't something like this blocked on the lack of specialisation?
replies(1): >>44395868 #
1. dwattttt ◴[27 Jun 25 11:20 UTC] No.44395868[source]▶
I believe the specific advice they're referring to has been stable for a while. You take your generic function & split it into a thin generic wrapper, and a non-generic worker.

As an example, say your function takes anything that can be turned into a String. You'd write a generic wrapper that does the ToString step, then change the existing function to just take a String. That way when your function is called, only the thin outer function is monomorphised, and the bulk of the work is a single implementation.

It's not _that_ commonly known, as it only becomes a problem for a library that becomes popular.

replies(1): >>44397255 #
2. estebank ◴[27 Jun 25 14:55 UTC] No.44397255[source]▶
To illustrate:

  fn foo<S: Into<String>>(s: S) {
      fn inner(s: String) { ... }
      inner(s.into())
  }
replies(1): >>44399834 #
3. ◴[27 Jun 25 20:08 UTC] No.44399834[source]▶