Build Performance Chapter

[epage]

Summary

Discussed on Zulip
Documentation: https://doc.rust-lang.org/nightly/cargo/guide/build-performance.html

Implementation

• Add "Optimizing Build Performance" section to the Cargo book #15924
• Add parallel frontend to the build performance guide #15970
• Add alternative linker to the build performance guide #15991
• docs(guide): Point out tools for reducing dependencies #16078
• docs(guide): Talk about removing unused features #16085
• docs(guide): Cover feature-unification #16108
• Anti-virus
  • Gatekeeper, https://corrode.dev/blog/tips-for-faster-rust-compile-times/#macos-only-exclude-rust-compilations-from-gatekeeper
  • Windows security, https://corrode.dev/blog/tips-for-faster-rust-compile-times/#windows-only-set-up-dev-drive-for-rust
• Special drive
  • Windows Dev Drive, https://corrode.dev/blog/tips-for-faster-rust-compile-times/#windows-only-set-up-dev-drive-for-rust
  • Other, https://corrode.dev/blog/tips-for-faster-rust-compile-times/#use-a-scratch-disk-for-faster-builds

Unresolved Issues

No response

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[epage]

We might want a section on de-monomorphization

• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#generics-use-an-inner-non-generic-function
• https://llogiq.github.io/2019/05/18/momo.html
• https://llogiq.github.io/2019/10/28/momo-fast.html
• Feature request: Use 'trampolines' to make most of the body of a generic function non-generic rust#77960
• Code bloat from monomorphization of methods applied to arrays rust#77767
• cargo-llvm-lines (for finding heavy generics with lots of copies)

Should we also create an issue for clippy for a new lint that highlights where people can do this?

[epage]

We might also want a splitting package section

• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#split-big-crates-into-smaller-ones-using-workspaces
• Issues with orphan rules
• Loss of dead code detection

[epage]

We might want a profiling builds section

• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#find-the-slow-crate-in-your-codebase
• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#profile-compile-times
• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#find-the-root-cause-for-rebuilds
• https://corrode.dev/blog/tips-for-faster-rust-compile-times/#find-expensive-proc-macros

[epage]

We might want to cover merging test binaries

• https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html
• cargo test: option to run all tests under the same binary #13450

[epage]

We might want to cover putting unit tests in a separate mod

• https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html
• New inline_test_mod lint to encouage independent test.rs files for rebuild performance rust-clippy#13589

[epage]

Should we have a non-answers section to record things that are off the beaten path enough that we would discourage?

I regularly see people suggest sharing target-dir across projects without any caveats but

• If they do it, it should be build-dir to reduce the chance of collisions for final artifacts which aren't scoped by a hash
• Even with the above, some artifacts will still collide, particularly on Windows. We are working to stabilize a new build-dir layout that will reduce this but it likely won't be eliminated yet.
• The amount of reuse is likely low because you'll get separate cache entries for different features being enabled between the package and its dependencies as well as if any dependency version is different.
• cargo clean will delete everything
• If the cache for one project gets poisoned, you'll likely need to get rid of the whole cache
• This will lead to more lock contention, slowing things down. Soon after a new build-dir layout rolls out, I'm hoping we'll have made changed the locking scheme to have less contention but it will likely be between cargo check, cargo clippy, and cargo build and not between two cargo checks, even if they have different --features

The planned way of resolving this is #5931.

[nik-rev]

I haven't seen sccache mentioned.

In my project, rm -rf target ; cargo build took 8-10 seconds. After using sccache, the first build took 32 seconds, but subsequent builds took 4 seconds each:

[build]
rustc-wrapper = "sccache"

Worth a read: Why you need sccache