3 ms·

Compile times are Rust's single biggest weakness. A lot of work is going into speeding up the compiler, but right now, the biggest wins in compile time reductio

Compile times are Rust's single biggest weakness. A lot of work is going into speeding up the compiler, but right now, the biggest wins in compile time reduction come from reorganizing your own code and eliminating overly generic dependencies, particularly those that introduce loads of transitive dependencies for building procedural macros. Clap and Serde are major offenders here. For many projects, eliminating such dependencies can speed up build times by a factor of 10 (and similarly reduce disk usage). Depending on your circumstances, it can be worth the effort.

tantalor 2y ago
TIL, this is missing context, thanks for explaining.
wging 2y ago
I don't think speed of a full compile (including your dependencies) is the right thing to optimize for -- and incremental compiles don't rebuild dependencies. In a project that depends on serde, for example, most compiles in an ordinary dev cycle are probably not recompiling serde. And sccache reduces the incidence of unnecessary rebuilds far further. Even clean builds tend to get through my dependencies quite quickly.
epage 2y ago
Except for the most trivial programs, clap should not make a factor of 10 difference, especially for incremental builds. For serde, I can see it if you use it a lot. There is an experiment to try to cache the macro expansion results to not need to run macro expansion during incremental builds. For full rebuilds, there is an in-work PR to decouple serde's traits from the derive so deserializers can be built in parallel to the rest of your serde code. There is also an RFC for declarative derives. Likely, serde won't be able to use it immediately but we'd like to get it to the point that serde can, getting rid of some big dependencies.
saghm 2y ago
It's worth noting that compiling the same code split up into separate crates compared to in a single crate will usually be faster due to the fact that cargo parallelizes per crate. That doesn't mean that having fewer dependencies won't still potentially help due to reducing the total amount of code that needs to be compiled, or that you couldn't split up the code you're writing yourself into separate crates, but if you're looking to bring in a dependency, the number of transitive dependencies you'd be bringing in as a result isn't necessarily going to be a good heuristic for the amount of extra compile time you'd be adding. In particular, a lot of packages that provide a large amount of functionality are already split up by those developers and then "combined" into a single package that brings them in as dependencies for this exact reason. If they're doing this right, they'll often have these exposed via cargo features that you can disable is they're not needed, and I'd argue that before looking to entirely swap out a direct dependency they're currently using, it's worth checking if the "bloat" they're unhappy with is actually something they can just disable via the feature set in cargo. Notably, a lot of the "extra" stuff that people have mentioned elsewhere in this thread is stuff that you can potentially turn off when using clap for arg parsing; looking at the documentation[1] to refresh myself, you can opt out of any combination of output color, automatic help text generation, automatic usage documentation, additional context being added to errors, and automatic generation of suggestions when the command is invoked incorrectly, and some of the stuff like being able to derive implementations by default and specific support for Unicode is already off by default. [1]: https://docs.rs/clap/latest/clap/_features/index.html https://docs.rs/clap/latest/clap/_features/index.html

tantalor 2y ago

TIL, this is missing context, thanks for explaining.

wging 2y ago

I don't think speed of a full compile (including your dependencies) is the right thing to optimize for -- and incremental compiles don't rebuild dependencies. In a project that depends on serde, for example, most compiles in an ordinary dev cycle are probably not recompiling serde. And sccache reduces the incidence of unnecessary rebuilds far further. Even clean builds tend to get through my dependencies quite quickly.

epage 2y ago

Except for the most trivial programs, clap should not make a factor of 10 difference, especially for incremental builds. For serde, I can see it if you use it a lot. There is an experiment to try to cache the macro expansion results to not need to run macro expansion during incremental builds. For full rebuilds, there is an in-work PR to decouple serde's traits from the derive so deserializers can be built in parallel to the rest of your serde code. There is also an RFC for declarative derives. Likely, serde won't be able to use it immediately but we'd like to get it to the point that serde can, getting rid of some big dependencies.

saghm 2y ago

It's worth noting that compiling the same code split up into separate crates compared to in a single crate will usually be faster due to the fact that cargo parallelizes per crate. That doesn't mean that having fewer dependencies won't still potentially help due to reducing the total amount of code that needs to be compiled, or that you couldn't split up the code you're writing yourself into separate crates, but if you're looking to bring in a dependency, the number of transitive dependencies you'd be bringing in as a result isn't necessarily going to be a good heuristic for the amount of extra compile time you'd be adding. In particular, a lot of packages that provide a large amount of functionality are already split up by those developers and then "combined" into a single package that brings them in as dependencies for this exact reason. If they're doing this right, they'll often have these exposed via cargo features that you can disable is they're not needed, and I'd argue that before looking to entirely swap out a direct dependency they're currently using, it's worth checking if the "bloat" they're unhappy with is actually something they can just disable via the feature set in cargo. Notably, a lot of the "extra" stuff that people have mentioned elsewhere in this thread is stuff that you can potentially turn off when using clap for arg parsing; looking at the documentation[1] to refresh myself, you can opt out of any combination of output color, automatic help text generation, automatic usage documentation, additional context being added to errors, and automatic generation of suggestions when the command is invoked incorrectly, and some of the stuff like being able to derive implementations by default and specific support for Unicode is already off by default. [1]: https://docs.rs/clap/latest/clap/_features/index.html https://docs.rs/clap/latest/clap/_features/index.html