Compile Times

Although this book is primarily about improving the performance of Rust programs, this section is about reducing the compile times of Rust programs, because that is a related topic of interest to many people.

Linking

A big part of compile time is actually linking time, particularly when rebuilding a program after a small change. On Linux and Windows you can select lld as the linker, which is much faster than the default linker.

To specify lld from the command line, precede your build command with RUSTFLAGS="-C link-arg=-fuse-ld=lld".

To specify lld from a config.toml file (for one or more projects), add these lines:

[build]
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

lld is not fully supported for use with Rust, but it should work for most use cases on Linux and Windows. There is a GitHub Issue tracking full support for lld.

Incremental Compilation

The Rust compiler supports incremental compilation, which avoids redoing work when you recompile a crate. It can greatly speed up compilation, at the cost of sometimes making the produced executable run a little more slowly. For this reason, it is only enabled by default for debug builds. If you want to enable it for release builds as well, add the following lines to the Cargo.toml file.

[profile.release]
incremental = true

See the Cargo documentation for more details about the incremental setting, and about enabling specific settings for different profiles.

Visualization

Cargo has a feature that lets you visualize compilation of your program. Build with this command:

cargo +nightly build -Ztimings

On completion it will print the name of an HTML file. Open that file in a web browser. It contains a Gantt chart that shows the dependencies between the various crates in your program. This shows how much parallelism there is in your crate graph, which can indicate if any large crates that serialize compilation should be broken up. See the documentation for more details on how to read the graphs.

LLVM IR

The Rust compiler uses LLVM for its back-end. LLVM’s execution can be a large part of compile times, especially when the Rust compiler’s front end generates a lot of IR which takes LLVM a long time to optimize.

These problems can be diagnosed with cargo llvm-lines, which shows which Rust functions cause the most LLVM IR to be generated. Generic functions are often the most important ones, because they can be instantiated dozens or even hundreds of times in large programs.

If a generic function causes IR bloat, there are several ways to fix it. The simplest is to just make the function smaller. Example.

Another way is to move the non-generic parts of the function into a separate, non-generic function, which will only be instantiated once. Whether or not this is possible will depend on the details of the generic function. The non-generic function can often be written as an inner function within the generic function, to minimize its exposure to the rest of the code. Example.

Sometimes common utility functions like Option::map and Result::map_err are instantiated many times. Replacing them with equivalent match expressions can help compile times.

The effects of these sorts of changes on compile times will usually be small, though occasionally they can be large. Example.