Build Performance Chapter

[epage]

Summary

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

Implementation

• [x] #15924
• [x] #15970
• [x] #15991
• [x] #16078
• [x] #16085
• [x] #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
• https://github.com/rust-lang/rust/issues/77960
• https://github.com/rust-lang/rust/issues/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
• https://github.com/rust-lang/cargo/issues/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
• https://github.com/rust-lang/rust-clippy/issues/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.