Last time I checked [1], the Rust part of the Rust compiler is not the slowest. LLVM spends a lot of time processing relatively poor IR code which the Rust compiler emits.

Rust compilation is not intrinsically slow; better IR and more incremental compilation can and will improve it. Incremental compilation (only changed files, not crates) is 7 years in making though.

[1]: https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow

Thanks for that link! That sounds like the really major factor is the decision to recompile the entire crate when a file in the crate changes. I'm sure that made sense at the time ;) And, if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision - incremental compilation might have its edge cases and pitfalls, but other compilers are doing it just fine, so it shouldn't be rocket science?

Other reasons:

- suboptimal LLVM IR code, as you mentioned, and other tech debt

- the preferred strategy of monomorphising generics is fast at runtime, but slow to compile, using trait objects is faster

- the complex type system of course also plays a part

- LLVM itself is of course not optimized for Rust

> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision

I'm not sure it was a "bad decision" if it was something that can be addressed after the fact and allowed them to ship working software more quickly.

The vast majority of the popular projects I am aware of have this kind of technical debt, likely due to survivorship bias. Project teams that refuse to take on technical debt are rarely successful enough to become popular.

> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision

Maybe we are giving Rust developers computers that are too fast. ;-)

OTOH, it's always wise to design for the future, so it also makes sense to give Rust developers beefy server grade hardware so they can play with SIMD pipelines and all those extra cores and threads, because that's what workstations will be a couple years from now.

In this case I really have to nitpick about the use of "C/C++": This specific problem really only exists in C++, because there it is common to put implementation code into headers via inline and template functions (worst example is the C++ stdlib), while in C you only put declarations into headers, and just parsing a few hundred lines of struct and function declarations won't blow up your build times (while just including a common C++ stdlib header like <vector> pulls in tens of thousands of lines of tricky template code.

In VC++ "import std", which imports the whole C++ standard library, is faster than just doing "#include <iostreams>".

It is only a matter of time, until GCC and clang finally catch up.

According to Wikipedia, both have support for precompiled headers: https://en.m.wikipedia.org/wiki/Precompiled_header

Shouldn't this be enough? Or does it require explicitly including the precompiled header whereas VC++ has magic to make that transparent?

C++20 modules and pre-compiler headers aren't the same thing in terms of technology.