Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/doc/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@
* [Continuous Integration](guide/continuous-integration.md)
* [Publishing on crates.io](reference/publishing.md)
* [Cargo Home](guide/cargo-home.md)
* [Optimizing Build Performance](guide/build-performance.md)

* [Cargo Reference](reference/index.md)
* [The Manifest Format](reference/manifest.md)
Expand Down
71 changes: 71 additions & 0 deletions src/doc/src/guide/build-performance.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have some "tips" at https://doc.rust-lang.org/nightly/cargo/reference/timings.html, should we switch that to a link to this page?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe fold that page into this one and setup a redirect

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to include a "how to profile my builds" in this page, which could link to the timings page as one of the points. And the timings page could then cross-link here for "how to optimize build perf.".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering bringing up dividing this into two sections

  • Root causing build times (--timings, compiler passes, macro lines, cargo llvm-lines)
  • Optimizing builds

I was just split on that vs framing those in terms of the current organization. For example, we could have a section on reducing the impact of generics and talk through using cargo llvm-lines to find large, repeated generic functions and discuss how to improve that.

Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# Optimizing Build Performance

Cargo uses configuration defaults that try to balance various aspects, including debuggability, runtime performance, build performance, binary size and others. Because of that, build performance is sometimes traded off for other benefits which may not be as important for your circumstances. This guide will step you through changes you can make to improve build performance.

Same as when optimizing runtime performance, be sure to measure these changes against the workflows you actually care about, as we provide general guidelines and your circumstances may be different.

Example workflows to consider include:
- Compiler feedback as you develop (`cargo check` after making a code change)
- Test feedback as you develop (`cargo test` after making a code change)
- CI builds

All approaches described below require you to modify [Cargo configuration](#where-to-apply-configuration-changes). Note that some of them currently require using the nightly toolchain.

## Reduce amount of generated debug information

Recommendation: Add to your `Cargo.toml` or `.cargo/config.toml`:

```toml
[profile.dev]
debug = "line-tables-only"

[profile.dev.package."*"]
debug = false

[profile.debugging]
inherits = "dev"
debug = true
```

This will:
- Change the [`dev` profile](../reference/profiles.md#dev) (default for development commands) to:
- Limit [debug information](../reference/profiles.md#debug) for workspace members to what is needed for useful panic backtraces
- Avoid generating any debug information for dependencies
- Provide an opt-in for when debugging via [`--profile debugging`](../reference/profiles.md#custom-profiles)

Trade-offs:
- ✅ Faster per-crate build times
- ✅ Faster link times
- ✅ Smaller disk usage of the `target` directory
- ❌ Requires a full rebuild to have a high-quality debugger experience

## Use an alternative codegen backend

> **This requires nightly/unstable features**

The component of the Rust compiler that generates executable code is called a "codegen backend". The default backend is LLVM, which produces very optimized code, at the cost of relatively slow compilation time. You can try to use a different codegen backend in order to speed up the compilation of your crate.

You can use the [Cranelift](https://github.com/rust-lang/rustc_codegen_cranelift) backend, which is designed for fast(er) compilation time. You can install this backend using rustup:

```console
$ rustup component add rustc-codegen-cranelift-preview --toolchain nightly
```

and then enable it for a given Cargo profile using the `codegen-backend` option in `Cargo.toml`:
```toml
[profile.dev]
codegen-backend = "cranelift"
```

Since this is currently an unstable option, you will also need to either pass `-Z codegen-backend` to Cargo, or enable this unstable option in the `.cargo/config.toml` file. You can find more information about the unstable `codegen-backend` profile option [here](../reference/unstable.md#codegen-backend).

Note that the Cranelift backend might not support all features used by your crate. It is also available only for a limited set of targets.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is also available only for a limited set of targets.

That might be an issue without #4897



## Where to apply configuration changes

You can apply the configuration changes described above in several places:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to be careful here because a lot of users are confused about what can go in Cargo.toml and what can go in .cargo/config.toml.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now it says

You can set the described options either in the Cargo.toml manifest, which will make them available for all developers who work on the given crate/project, or in the config.toml configuration file, where you can apply them only for you or even globally for all your local projects.

Depending on how this evolves, not everything will be supported in both locations

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can iterate further on this as we add more content


- If you apply them to the `Cargo.toml` manifest, they will affect all developers who work on the given crate/project.
- If you apply them to the `<workspace>/.cargo/config.toml` file, they will affect only you (unless this file is checked into version control).
- If you apply them to the `$CARGO_HOME/.cargo/config.toml` file, they will be applied globally to all Rust projects that you work on.
1 change: 1 addition & 0 deletions src/doc/src/guide/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,3 +13,4 @@ develop Rust packages.
* [Continuous Integration](continuous-integration.md)
* [Publishing on crates.io](../reference/publishing.md)
* [Cargo Home](cargo-home.md)
* [Optimizing Build Performance](build-performance.md)
Loading