Perhaps the most often repeated complaint about Rust is its slow feedback loop and long compilation times. I hear about it all the time; in Rust podcasts, blog posts, surveys, conference talks or offline discussions. I also regularly complain about it, being a Rust user myself!
Recently, in addition to the usual compile times complaints, I also started noticing the following sentiments being expressed by frustrated Rust developers: “Why doesn’t the Rust Project care more about this pressing and known issue? Why don’t they do something about it?”. As a member of the Rust compiler performance working group, I take these questions very seriously, and I of course have some opinions on the topic. In this blog post, I would like to offer some thoughts that might serve as answers to these (and other similar) questions.
Disclaimer: all opinions expressed in this post are mine only and do not necessarily represent the broader views of the Rust Project (the diverse set of contributors and maintainers that contribute to the Rust toolchain).
Do we even care?
First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it. We triage performance improvements and regressions each week. We run a comprehensive benchmark suite after every merged PR . We enthusiatically welcome any performance improvements (unless they have complicated trade-offs, more on that later), and try to quickly revert (or fix) PRs that introduce performance regressions. Very smart people are continously working on finding bottlenecks and speeding up the compiler. And some significant improvements to make compilation faster by default are currently in the works.
And all this effort shows results; Rust build performance has improved quite a lot over the past few years! When we talk about the long-term trends, we usually show this dashboard, but I find it a bit dull, because it averages results of several benchmarks together and the benchmarks are quite short, so they start running into diminishing returns. Instead, I did a little experiment to show how did the build performance evolve on my favourite test subject, hyperqueue. I took its first commit (from March 2021) and compiled it with a few different Rust compiler versions, with ~1 year increments between them. I did this on a relatively modest laptop with 8 AMD cores running Linux. Here are the results:
rustc version Clean build [s] Incremental rebuild [s] Speedup (clean build) 1.61.0 (May 2022) 26.1s ~0.39 - 1.70.0 (June 2023) 20.2s ~0.37 1.29x 1.78.0 (May 2024) 17.0s ~0.30 1.53x 1.87.0 (May 2025) 14.7s ~0.26 1.77x
On this benchmark, the compiler is almost twice as fast than it was three years ago. Of course, this is just a single data point, in different cases the speedup will be larger or smaller, and it will likely be smaller in general on other platforms than x64 Linux, because we spend the most effort optimizing that specific target. But the fact remains that the performance of the compiler is continuously improving.
It’s still not fast enough though
Now, all that is nice, but it doesn’t change the fact that for many Rust developers, compilation performance is still a big bottleneck, and they could be much more productive if the feedback loop was an order of magnitude (or more) faster. To be fair, this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times, while Python programmers likely aren’t very impressed by Rust’s feedback loop speed. But it’s definitely not a stretch to say that for many users, Rust compilation just isn’t fast enough today, and that is a problem.
... continue reading