3 ms·

Rust is most definitely slow to compile compared to GCC or LLVM for C/C++. This is a known situation and has been since the pre-1.0 days because of the heavily

Rust is most definitely slow to compile compared to GCC or LLVM for C/C++. This is a known situation and has been since the pre-1.0 days because of the heavily front-loaded macro and borrow systems. It's the tradeoff you have for having a "safe" language vs a "trusting" one. I would argue that it's not as bad as it's made out to be, especially if you're not doing full recompiles and using it on modern (2019+) hardware; but it is a noticeable difference in similar large codebases.

rowanG077 4y ago
It's slower then C for sure. But slower then C++? I doubt it.
- est31 4y ago
  Rust is most comparable to C++ with heavy TMP, as it itself also makes use of templates.
  - kibwen 4y ago
    To be precise, Rust generics perform monomorphization, which C++ templates also perform. But I wouldn't go so far as to compare the language to "C++ with heavy TMP", as that's far too broad of a characterization; TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit.
    - est31 4y ago
      > TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit. That's fair. My comment was mostly about performance.
- pjmlp 4y ago
  C++ is only slower in heavy template metaprogramming. Additionally thanks to heavy reliance on binary libraries, when starting a new project, we only need to compile our own code.
est31 4y ago
Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm optimizations and such. The issue is more Rust's generics as they cause a lot of code to be passed to llvm (among other issues for Rust's slowness).
- Arnavion 4y ago
  Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1] This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2] [1]: https://github.com/Arnavion/k8s-openapi/issues/4 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*
  - est31 4y ago
    > Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.

rowanG077 4y ago

It's slower then C for sure. But slower then C++? I doubt it.

est31 4y ago
Rust is most comparable to C++ with heavy TMP, as it itself also makes use of templates.
- kibwen 4y ago
  To be precise, Rust generics perform monomorphization, which C++ templates also perform. But I wouldn't go so far as to compare the language to "C++ with heavy TMP", as that's far too broad of a characterization; TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit.
  - est31 4y ago
    > TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit. That's fair. My comment was mostly about performance.
pjmlp 4y ago
C++ is only slower in heavy template metaprogramming. Additionally thanks to heavy reliance on binary libraries, when starting a new project, we only need to compile our own code.

est31 4y ago

Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm optimizations and such. The issue is more Rust's generics as they cause a lot of code to be passed to llvm (among other issues for Rust's slowness).

Arnavion 4y ago
Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1] This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2] [1]: https://github.com/Arnavion/k8s-openapi/issues/4 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*
- est31 4y ago
  > Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.