4 ms·

When people complain about rust compile times are they complaining about cold/clean compiles or warm/cached compiles? I can never really tell because people jus

by dcow 4y ago

When people complain about rust compile times are they complaining about cold/clean compiles or warm/cached compiles? I can never really tell because people just gripe "compile times". I can see how someone would come to rust, type `cargo run`, wait 3-5 minutes while cargo downloads all the dependencies and compiles them along with the main package, and then say, "well that took awhile it kinda sucks". But if they change a few lines in the actual project and compile again it would be near instant. The fair comparison would be something akin to deleting your node or go modules and running a cold build. I am slightly suspicious, not in a deliberate foul play way but more in a messy semantics and ad-hoc anecdotes way, that many of these compile time discrepancies probably boil down more to differences in how the cargo tooling handles dependencies and what it decides to include in the compile phase, where it decides to store caches and what that means for `clean`, etc. compared to similar package management tooling from other languages, than it does to "rustc is slow". But I could be wrong.

codetrotter 4y ago
> But if they change a few lines in the actual project and compile again it would be near instant. If it’s a big project and the lines you are changing are in something that is being used many other places then the rebuild will still take a little while. (30 seconds or a minute, or more, depending on the size of the project.) Likewise, if you work on things in different branches you may need to wait more when you switch branch and work on something there. Also if you switch between Rust versions you need to wait a while when you rebuild your project. I love Rust, and I welcome everything that is being done to bring the compile times down further!
- Lewton 4y ago
  > (30 seconds or a minute, or more, depending on the size of the project.) I'm working on a largeish modern java project using gradle, and this sounds great... Every time I start my server it takes 40 seconds just for gradle to find out that all the sub projects are up to date, nothing has been changed and no compilation is necessary...
  - wtetzner 4y ago
    Yeah, even Maven seems much faster than Gradle, even on a clean build. Neither are especially fast though.
- dcow 4y ago
  I am not discouraging efforts to make compile times faster. However, I also see a lot of things that would really make Rust soar not being worked on, like syntax quality of life reworks that get complex under the hood being dropped, partially complete features with half baked PRs, IDE tooling and debugging support, interface-types and much of the momentum behind wasm, async traits and the sorely lacking async_std, etc. It seems like every time I dive into something moderately complex I start hitting compiler caveats with links to issues that have been open for 5 years and a bunch of comments like "what's the status of this can we please get this merged?". It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times.
  - insanitybit 4y ago
    > "what's the status of this can we please get this merged?" Having written Rust professionally for a number of years, this didn't happen too much. Where it did it was stuff like "yeah you need to Box the thing today", which... did not matter, we just did that and moved on. > It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times. That is generally my feeling about Rust. There are a few areas where I'd like to see things get wrapped up (async traits, which are being actively worked on) but otherwise everything feels like a bonus. In terms of things that made Rust difficult to use, yeah, compile times were probably the number one.
    - nicoburns 4y ago
      There are a few more fundemental missing pieces for me: - It's impossible to describe a type that "implements trait A and may or may not implement trait B" - It's impossible to be generic over a trait (not a type that implements a trait, the trait itself)
      - tialaramex 4y ago
        > It's impossible to describe a type that "implements trait A and may or may not implement trait B" How is this different from just describing a type that only "implements trait A" ?
- wongarsu 4y ago
  For the branch-switching usecase you might get some milage out of sccache [1]. For local storage it's just one binary and two lines of configuration to have a cache around rustc, so it's worth testing out. 1: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
anuraaga 4y ago
cargo run is a command you'd generally use to actually get something running I guess. This is not going to be incremental development in many cases which focus on unit tests I guess. FWIW cold builds (i.e., in docker with no cache) of cargo are much slower than go, hanging for a long time on refreshing cargo.io indexes. I don't know exactly what that is doing but I have a feeling it is implemented in a monolithic way rather than on-demand. Rust has had plenty of time to make this better but it is still very slow for cold cargo builds, often spending minutes refreshing the crates index. But Go misses easy optimizations like creating strings from a byte slice. So it is what it is - Go makes explicit promises of fast compile times. Thanks to that, build scripts in go are pretty fast. Any language that doesn't make that explicit might be slow to compile and might run fast - that's totally fine and I would rather have two languages optimized to each case than one mediocre language.
- dwattttt 4y ago
  Refreshing the crates index has gotten quite slow because it currently downloads the entire index, regardless of which bits you need. There's a trial of a new protocol happening now, due for release in March, that should speed this up (https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-sparse-protocol.html https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-spar...)
- zozbot234 4y ago
  You don't even need a separate language, there's already a "fast" compiler for Rust based on cranelift which is used in debug builds by default.
  - burntsushi 4y ago
    Cranelift is not used for debug builds by default. I think that's probably a goal (although I'm not actually 100% sure about that just because I'm not dialed into what the compiler team is doing). Even the OP mentions this: > We were able to benchmark bjorn3's cranelift codegen backend on full crates as well as on the build dependencies specifically (since they're also built for cargo check builds, and are always built without optimizations): there were no issues, and it performed impressively. It's well on its way to becoming a viable alternative to the LLVM backend for debug builds. And the Cranelift codegen backend itself is also clear about it not being ready yet: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift (To be clear, I am super excited about using Cranelift for debug builds. I just want to clarify that it isn't actually used by default yet.)
zozbot234 4y ago
Practically all Rust crates make heavy use of monomorphized generics, so every use of them in a new project is bespoke and has to be compiled on the spot. This is very different from how Go or Node work. You could compile the non monomorphic portions of a Rust crate into a C-compatible system library (with a thin, header-like wrapper to translate across ABI's) but in practice it wouldn't amount to much.
- Tobu 4y ago
  Some popular proc-macros could be pre-compiled and distributed as WASM, and it would be impactful, since they tend to bottleneck the early parts of a project build. However I don't think that could be made entirely transparent, because right now there's a combinatorial explosion of possible syn features. For now I avoid depending on syn/quote if I can.
insanitybit 4y ago
It's a few things: 1. Clean builds can happen more often than some may think. CI/CD pipelines can end up with a lot of clean builds - especially if you use ephemeral instances (to save money), but even if you don't it's very likely. Even locally it can happen sometimes. For example, we used Docker to run builds. For various reasons the cache could get blown. Also, sometimes weird systemy things happen and 'cargo clean' fixes it, but you have to recompile from scratch. This can take 10+ minutes on a decent sized codebase. 2. On a large codebase even small changes can lead to long recompile times, especially if you want to run tests - cargo check won't be enough, you need to build.
dmm 4y ago
Incremental builds are what matter to me. On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5. That's all build time the tests run in <100ms. The incremental build performance seems to be really dependent on single-thread performance. An incremental build on a 2014ish Haswell e5-2660v3 xeon takes ~30s.
- kibwen 4y ago
  > On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5 `cargo test` and default `cargo build` use the same profile, so presumably the first number is referring to `cargo build --release`. Release builds deliberately forego compilation speed in favor of optimization. In practice, most of my development involves `cargo check`, which is much faster than `cargo build`.
  - dmm 4y ago
    > so presumably the first number is referring to `cargo build --release` Both numbers are for debug builds. I don't know why `cargo test` is faster but I appreciate it. Incremental release builds with `cargo build --release` are even slower taking ~35s on the 1240p.
    - dureuill 4y ago
      i suspect most of that time is link time. Possibly the linker in use is not very parallel, and so linking one big executable with cargo build takes longer than many smaller test executable whose linking can actually be made parallel?
      - scns 4y ago
        Using mold might help in this case. https://github.com/rui314/mold https://github.com/rui314/mold https://github.com/rust-lang/rust/issues/94347 https://github.com/rust-lang/rust/issues/94347
    - 4y ago
pjmlp 4y ago
Both, because some times a little change implies compiling the world due to configuration changes. Also it is quite irritating sometimes seeing the same crate being compiled multiple times as it gets referenced from other crates. Ideally Rust could use a dumb compilation mode (or interpreter) for change-compile-debug cycles, and proper compilation for release, e.g. Haskell and OCaml offer such capabilities on their toolchains.
- titzer 4y ago
  I primarily develop the Virgil compiler in interpreted mode (i.e. running the current source on the stable binary's interpreter). Loading and typechecking ~45kloc of compiler source takes 80ms, so it is effectively instantaneous.
  - pjmlp 4y ago
    Yeah it works great having toolchains that support all possible execution models.
  - sitkack 4y ago
    But you aren't on our timeline and haven't opted into our bullshit. HTML+Js projects used to be testable with the load of a web page and that community has opt-in to long build times. Most people are so far away from flow-state that they can't even imagine another way of being.
    - scns 4y ago
      Mhm, maybe twas a bad idea to start learning React with ReasonML. Being used to compiles in milliseconds made the collision with TS at $Job extra painful.
conaclos 4y ago
I contributed to Rome tools [1] and the build takes more than 1 min. This makes write-build-test loop frustrating... Such frustrating that I am hesitating to start a project in Rust... My machine is 7yo. People tell me to buy a new one just for compiling a Rust project... That's ecologically questionable. [1] https://rome.tools/ https://rome.tools/
- kristianp 4y ago
  I'd say if you got a newer system, the SSD speed of the new system would be at least 2x of the old one. That's got to help at least the linking step substantially.

by dcow 4y ago

codetrotter 4y ago

> But if they change a few lines in the actual project and compile again it would be near instant. If it’s a big project and the lines you are changing are in something that is being used many other places then the rebuild will still take a little while. (30 seconds or a minute, or more, depending on the size of the project.) Likewise, if you work on things in different branches you may need to wait more when you switch branch and work on something there. Also if you switch between Rust versions you need to wait a while when you rebuild your project. I love Rust, and I welcome everything that is being done to bring the compile times down further!

Lewton 4y ago
> (30 seconds or a minute, or more, depending on the size of the project.) I'm working on a largeish modern java project using gradle, and this sounds great... Every time I start my server it takes 40 seconds just for gradle to find out that all the sub projects are up to date, nothing has been changed and no compilation is necessary...
- wtetzner 4y ago
  Yeah, even Maven seems much faster than Gradle, even on a clean build. Neither are especially fast though.
dcow 4y ago
I am not discouraging efforts to make compile times faster. However, I also see a lot of things that would really make Rust soar not being worked on, like syntax quality of life reworks that get complex under the hood being dropped, partially complete features with half baked PRs, IDE tooling and debugging support, interface-types and much of the momentum behind wasm, async traits and the sorely lacking async_std, etc. It seems like every time I dive into something moderately complex I start hitting compiler caveats with links to issues that have been open for 5 years and a bunch of comments like "what's the status of this can we please get this merged?". It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times.
- insanitybit 4y ago
  > "what's the status of this can we please get this merged?" Having written Rust professionally for a number of years, this didn't happen too much. Where it did it was stuff like "yeah you need to Box the thing today", which... did not matter, we just did that and moved on. > It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times. That is generally my feeling about Rust. There are a few areas where I'd like to see things get wrapped up (async traits, which are being actively worked on) but otherwise everything feels like a bonus. In terms of things that made Rust difficult to use, yeah, compile times were probably the number one.
  - nicoburns 4y ago
    There are a few more fundemental missing pieces for me: - It's impossible to describe a type that "implements trait A and may or may not implement trait B" - It's impossible to be generic over a trait (not a type that implements a trait, the trait itself)
    - tialaramex 4y ago
      > It's impossible to describe a type that "implements trait A and may or may not implement trait B" How is this different from just describing a type that only "implements trait A" ?
wongarsu 4y ago
For the branch-switching usecase you might get some milage out of sccache [1]. For local storage it's just one binary and two lines of configuration to have a cache around rustc, so it's worth testing out. 1: https://github.com/mozilla/sccache https://github.com/mozilla/sccache

anuraaga 4y ago

cargo run is a command you'd generally use to actually get something running I guess. This is not going to be incremental development in many cases which focus on unit tests I guess. FWIW cold builds (i.e., in docker with no cache) of cargo are much slower than go, hanging for a long time on refreshing cargo.io indexes. I don't know exactly what that is doing but I have a feeling it is implemented in a monolithic way rather than on-demand. Rust has had plenty of time to make this better but it is still very slow for cold cargo builds, often spending minutes refreshing the crates index. But Go misses easy optimizations like creating strings from a byte slice. So it is what it is - Go makes explicit promises of fast compile times. Thanks to that, build scripts in go are pretty fast. Any language that doesn't make that explicit might be slow to compile and might run fast - that's totally fine and I would rather have two languages optimized to each case than one mediocre language.

dwattttt 4y ago
Refreshing the crates index has gotten quite slow because it currently downloads the entire index, regardless of which bits you need. There's a trial of a new protocol happening now, due for release in March, that should speed this up (https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-sparse-protocol.html https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-spar...)
zozbot234 4y ago
You don't even need a separate language, there's already a "fast" compiler for Rust based on cranelift which is used in debug builds by default.
- burntsushi 4y ago
  Cranelift is not used for debug builds by default. I think that's probably a goal (although I'm not actually 100% sure about that just because I'm not dialed into what the compiler team is doing). Even the OP mentions this: > We were able to benchmark bjorn3's cranelift codegen backend on full crates as well as on the build dependencies specifically (since they're also built for cargo check builds, and are always built without optimizations): there were no issues, and it performed impressively. It's well on its way to becoming a viable alternative to the LLVM backend for debug builds. And the Cranelift codegen backend itself is also clear about it not being ready yet: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift (To be clear, I am super excited about using Cranelift for debug builds. I just want to clarify that it isn't actually used by default yet.)

zozbot234 4y ago

Practically all Rust crates make heavy use of monomorphized generics, so every use of them in a new project is bespoke and has to be compiled on the spot. This is very different from how Go or Node work. You could compile the non monomorphic portions of a Rust crate into a C-compatible system library (with a thin, header-like wrapper to translate across ABI's) but in practice it wouldn't amount to much.

Tobu 4y ago
Some popular proc-macros could be pre-compiled and distributed as WASM, and it would be impactful, since they tend to bottleneck the early parts of a project build. However I don't think that could be made entirely transparent, because right now there's a combinatorial explosion of possible syn features. For now I avoid depending on syn/quote if I can.

insanitybit 4y ago

It's a few things: 1. Clean builds can happen more often than some may think. CI/CD pipelines can end up with a lot of clean builds - especially if you use ephemeral instances (to save money), but even if you don't it's very likely. Even locally it can happen sometimes. For example, we used Docker to run builds. For various reasons the cache could get blown. Also, sometimes weird systemy things happen and 'cargo clean' fixes it, but you have to recompile from scratch. This can take 10+ minutes on a decent sized codebase. 2. On a large codebase even small changes can lead to long recompile times, especially if you want to run tests - cargo check won't be enough, you need to build.

dmm 4y ago

Incremental builds are what matter to me. On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5. That's all build time the tests run in <100ms. The incremental build performance seems to be really dependent on single-thread performance. An incremental build on a 2014ish Haswell e5-2660v3 xeon takes ~30s.

kibwen 4y ago
> On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5 `cargo test` and default `cargo build` use the same profile, so presumably the first number is referring to `cargo build --release`. Release builds deliberately forego compilation speed in favor of optimization. In practice, most of my development involves `cargo check`, which is much faster than `cargo build`.
- dmm 4y ago
  > so presumably the first number is referring to `cargo build --release` Both numbers are for debug builds. I don't know why `cargo test` is faster but I appreciate it. Incremental release builds with `cargo build --release` are even slower taking ~35s on the 1240p.
  - dureuill 4y ago
    i suspect most of that time is link time. Possibly the linker in use is not very parallel, and so linking one big executable with cargo build takes longer than many smaller test executable whose linking can actually be made parallel?
    - scns 4y ago
      Using mold might help in this case. https://github.com/rui314/mold https://github.com/rui314/mold https://github.com/rust-lang/rust/issues/94347 https://github.com/rust-lang/rust/issues/94347
  - 4y ago

pjmlp 4y ago

Both, because some times a little change implies compiling the world due to configuration changes. Also it is quite irritating sometimes seeing the same crate being compiled multiple times as it gets referenced from other crates. Ideally Rust could use a dumb compilation mode (or interpreter) for change-compile-debug cycles, and proper compilation for release, e.g. Haskell and OCaml offer such capabilities on their toolchains.

titzer 4y ago
I primarily develop the Virgil compiler in interpreted mode (i.e. running the current source on the stable binary's interpreter). Loading and typechecking ~45kloc of compiler source takes 80ms, so it is effectively instantaneous.
- pjmlp 4y ago
  Yeah it works great having toolchains that support all possible execution models.
- sitkack 4y ago
  But you aren't on our timeline and haven't opted into our bullshit. HTML+Js projects used to be testable with the load of a web page and that community has opt-in to long build times. Most people are so far away from flow-state that they can't even imagine another way of being.
  - scns 4y ago
    Mhm, maybe twas a bad idea to start learning React with ReasonML. Being used to compiles in milliseconds made the collision with TS at $Job extra painful.

conaclos 4y ago

I contributed to Rome tools [1] and the build takes more than 1 min. This makes write-build-test loop frustrating... Such frustrating that I am hesitating to start a project in Rust... My machine is 7yo. People tell me to buy a new one just for compiling a Rust project... That's ecologically questionable. [1] https://rome.tools/ https://rome.tools/

kristianp 4y ago
I'd say if you got a newer system, the SSD speed of the new system would be at least 2x of the old one. That's got to help at least the linking step substantially.