Developers choose Rust because they can use it to write software that is memory-safe, correct, and—above all—fast. But the Rust compiler isn’t always the fastest car in the garage. The larger a Rust program is, and the more dependencies it has, the longer its compile time will be. A development process that once was a sprint slows to a creep.

Now for the good news: None of this is inevitable. Used smartly, many of the slowest parts of the Rust toolchain can be made quite snappy. Here’s a compendium of common techniques for speeding up Rust compilation. They are organized by strategy and general theme, and you can put them to work right now in your Rust projects.

1. Start with the basics

The single most effective thing you can do without changing anything about your existing work habits is to keep your Rust toolchain updated. You may already be doing this, but it’s worth a reminder.

Running rustup update periodically ensures you’re using the latest version of the compiler. This matters because Rust’s compiler team is constantly updating and optimizing the compilation process. Those optimizations aren’t just rolled into rustc itself, but also into LLVM, the framework rustc builds on top of.

If you’re reluctant to update the toolchain aggressively, because it might affect your project’s requirements, pin your project toolchain to a specific version, like so:

[toolchain]
channel = "1.85"

2. Don’t do anything you don’t have to

The golden rule of performance in computing, no matter what you’re doing: the less you do, the better. This absolutely applies to compiling Rust projects, since very often, a complete compilation isn’t needed.

Instead of a full compilation, you can run cargo check to perform most of the checks you need. This will ensure your code would compile, without having to actually compile the code. The former chiefly involves rustc’s checking mechanisms; the latter involves the LLVM-driven build process, which is far slower.

Note that cargo check will not skip compilation of as-yet-unbuilt dependencies. If they need to be built to run the check, they will be. But after the first cargo check to get caught up on that process, future check runs will complete far faster.

Another common way to avoid rebuilding is to use a compiler caching tool. The sccache project supports caching Rust compiler artifacts, along with several other popular languages with similar coompiler behaviors (C, C++, etc.). However, you get the best results with sccache or something like it when you use it as a build cache for multiple users—e.g., a development team in an organization with a shared file system. Used on one system alone, it doesn’t yield much of an advantage, unless you’re sharing build artifacts for the same versions of crates across multiple projects.

Another powerful way to avoid unneeded compilation is to wrap your dependencies as dynamically linked libraries (“dynlibs”). This isn’t native to Rust’s toolchain, though—it’s accomplished with a third party tool, cargo add-dynamic. Using the tool means you won’t get some of the benefits of compiling dependencies statically, like being able to inline code from crates. But it also speeds up the linking process dramatically, and while linking does get pushed off to runtime, its costs are typically minimal. The creator of cargo add-dynamic has written in detail about the ins and outs of this technique, using the polars data science library as an example.

3. Divide and conquer

The larger a project is, the less likely you need to recompile the entire thing if it’s divided along clean architectural lines. If you have a project with an MVC design, and you’re only making changes to the views that don’t involve altering its APIs, you can just recompile that portion of the project as you alter it.

To achieve something like this in Rust, you’d split up your project into multiple subcrates using Cargo workspaces. You’ll need to manually refactor existing single-crate projects, as there’s no native automated way to do this (unless you ask your friendly neighborhood LLM to help!). You’ll also benefit most from this selective recompilation in a project where you can split the codebase cleanly across well-defined boundaries, and where the project is big enough to justify partitioning. This blog post describes a fantastic (if extreme) application of this principle to efficiently compile SQL code converted at scale to Rust.

Another potential divide-and-conquer technique is parallel compilation, which is slowly becoming a feature that’s supported “out of the box” in the Rust compiler, instead of something you need to enable manually. If you use parallel compilation nightly, more of the parallel features are enabled by default; otherwise, you can use the compiler flag -Z threads= to enable it manually, where is how many threads to use.

To that end, don’t put too much emphasis on manually adding parallel code generation unless it provides a demonstrable benefit. One way to test this would be to run a completely clean build with parallelism at both full and half utilization—e.g., for an 8-core system, use 8 and 4 threads for the build process—and see if there’s any discernable benefit.

4. Analyze, analyze, analyze

It’s hard to know what to optimize without measurements. Fortunately, Rust’s cargo build comes with a powerful build-time reporting tool, the --timings switch. Run it and you’ll get a detailed HTML-formatted report that can help you pin down exactly what’s taking so long in the compilation process.

Sometimes the culprit isn’t merely in a given crate, but in a procedural macro used by some crate. A nightly-only flag for the compiler, -Zmacro-stats, generates information about the number of lines of code a given macro generates. This tells you how much code is being expanded from macros. That information may be a hint as to why a given crate may be the source of unexpectedly high compile times.

Another useful measure is to gauge how long each compilation step takes. The -Z time-passes compiler flag displays the elapsed time for each step, including LLVM’s overhead and the work done by the linker. Don’t sleep on how much time the linker takes; it’s an oft-underrated choke point for compilation. You can try switching linkers—experiment with lld or mold to see if your link times pick up.

5. Use platform-specific optimizations

If you’re stuck using Microsoft Windows (or if you actually want to use it), software projects belong on a new file system created specifically for development scenarios. The Dev Drive, as it’s called, uses a new file system, called ReFS, which has more proactive automatic-repair behavior (you don’t need to manually scan volumes), and also automatically reduces interference from Windows’s antivirus scanning.

Linux users can set up an in-memory temporary filesystem and use it for fast caching of compiled artifacts. The downside: Anything stored there is lost after rebooting. However, if you keep long uptimes for your workstation, you’ll only need to rebuild the cache once after rebooting.

Conclusion

The Rust compiler team keeps making strides to improve compilation times without requiring intervention from the developer. But there will always be places where the compiler alone can’t do the heavy lifting to make things faster. The more proactive you are about discovering where your project is slow to compile, the faster your Rust software will be.