You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two months ago, we launched the first [Rust Compiler Performance Survey](../rust-compiler-performance-survey-2025.md), with the goal of helping us understand the biggest pain points of Rust developers related to build performance. It is clear that this topic is very important for the Rust community, as the survey received over 3 700 responses! We would like to thank everyone who participated in the survey, and especially those who described their workflows and challenges with an open answer. We plan to run this survey annually, so that we can observe long-term trends in Rust build performance and its perception.
11
+
Two months ago, we launched the first [Rust Compiler Performance Survey][rust-compiler-performance-survey], with the goal of helping us understand the biggest pain points of Rust developers related to build performance. It is clear that this topic is very important for the Rust community, as the survey received over 3 700 responses! We would like to thank everyone who participated in the survey, and especially those who described their workflows and challenges with an open answer. We plan to run this survey annually, so that we can observe long-term trends in Rust build performance and its perception.
12
12
13
13
In this post, we'll show some interesting results and insights that we got from the survey and promote work that we have already done recently or that we plan to do to improve the build performance of Rust code. If you would like to examine the complete results of the survey, you can find them [here][report].
14
14
@@ -38,7 +38,7 @@ To understand the overall sentiment, we asked our respondents to rate their sati
38
38
</div>
39
39
<!-- Chart satisfaction end -->
40
40
41
-
To help us understand the overall build experience in more detail, we also analyzed all open answers (almost six hundred of them) written by our respondents, to help us identify several recurring themes, which we will discuss in this post.
41
+
To help us understand the overall build experience in more detail, we also analyzed all open answers (over a thousand of them) written by our respondents, to help us identify several recurring themes, which we will discuss in this post.
42
42
43
43
One thing that is clear from both the satisfaction rating and the open answers is that the build experience differs wildly across users and workflows, and it is not as clear-cut as "Rust builds are slow". We actually received many positive comments about users being happy with Rust build performance, and appreciation for it being improved vastly over the past several years to the point where it stopped being a problem.
44
44
@@ -78,7 +78,7 @@ We can see that all the workflows that we asked about cause significant problems
78
78
</div>
79
79
<!-- Chart problems end -->
80
80
81
-
Based on the answers to these two questions, and other experiences shared in the open answers, we identifified three groups of workflows that we will discuss next:
81
+
Based on the answers to these two questions and other experiences shared in the open answers, we identified three groups of workflows that we will discuss next:
82
82
83
83
- Incremental rebuilds after making a small change
84
84
- Type checking using `cargo check` or with a code editor
@@ -88,13 +88,13 @@ Based on the answers to these two questions, and other experiences shared in the
88
88
89
89
Waiting too long for an incremental rebuild after making a small source code change was by far the most common complaint in the open answers that we received, and it was also the most common problem that respondents said they struggle with. Based on our respondents' answers, this comes down to three main bottlenecks:
90
90
91
-
-**Changes in workspaces trigger unneccessary rebuilds.** If you modify a crate in a workspace that has several dependent crates and perform a rebuild, all those dependent crates will currently have to be recompiled. This can cause a lot of unnecessary work and dramatically increase the latency of rebuilds in large (or deep) workspaces. We have some ideas about how to improve this workflow, such as the ["Relink, don't rebuild"][project-goal-rdr] proposal, but these are currently in a very experimental stage.
92
-
-**The linking phase is too slow.** This was a very common complaint, and it is indeed a real issue, because unlike the rest of the compilation process, linking is always performed "from scratch". The Rust compiler usually delegates linking to an external/system linker, so its performance is not completely within our hands. However, we are attempting to switch to faster linkers by default. For example, the most popular target (`x86_64-unknown-linux-gnu`) has recently switched to the [LLD linker][rust-lld-blog-post], which provides significant performance wins. Long-term, it is possible that some linkers (e.g. [wild]) will allow us to perform even linking incrementally.
91
+
-**Changes in workspaces trigger unnecessary rebuilds.** If you modify a crate in a workspace that has several dependent crates and perform a rebuild, all those dependent crates will currently have to be recompiled. This can cause a lot of unnecessary work and dramatically increase the latency of rebuilds in large (or deep) workspaces. We have some ideas about how to improve this workflow, such as the ["Relink, don't rebuild"][project-goal-rdr] proposal, but these are currently in a very experimental stage.
92
+
-**The linking phase is too slow.** This was a very common complaint, and it is indeed a real issue, because unlike the rest of the compilation process, linking is always performed "from scratch". The Rust compiler usually delegates linking to an external/system linker, so its performance is not completely within our hands. However, we are attempting to switch to faster linkers by default. For example, the most popular target (`x86_64-unknown-linux-gnu`) will very soon switch to the [LLD linker][rust-lld-blog-post], which provides significant performance wins. Long-term, it is possible that some linkers (e.g. [wild]) will allow us to perform even linking incrementally.
93
93
-**Incremental rebuild of a single crate is too slow.** The performance of this workflow depends on the cleverness of the incremental engine of the Rust compiler. While it is already very sophisticated, there are some parts of the compilation process that are not incremental yet or that are not cached in an optimal way. For example, expansion of derive proc macros is not currently cached, although work is underway to [change that][cache-proc-macros].
94
94
95
95
Several users have mentioned that they would like to see Rust perform hot-patching (such as the `subsecond` system used by the Dioxus UI framwork or similar approaches used e.g. by the Bevy game engine). While these hot-patching systems are very exciting and can produce truly near-instant rebuild times for specialized use-cases, it should be noted that they also come with many limitations and edge-cases, and it does not seem that a solution that would allow hot-patching to work in a robust way has been found yet.
96
96
97
-
To gauge how long is the typical rebuild latency, we asked our respondents to pick a single Rust project that they work on and which causes them to struggle with build times the most, and tell us how longthey have to wait for it to be rebuilt after making a code change.
97
+
To gauge how long is the typical rebuild latency, we asked our respondents to pick a single Rust project that they work on and which causes them to struggle with build times the most, and tell us how long they have to wait for it to be rebuilt after making a code change.
98
98
99
99
<!-- Chart rebuild-wait-time start -->
100
100
<div>
@@ -154,7 +154,7 @@ Approximately 60% of respondents say that they use `cargo` terminal commands to
154
154
155
155
While the performance of `cargo check` does not seem to be as big of a blocker as e.g. incremental rebuilds, it also causes some pain points. One of the most common ones present in the survey responses is the fact that `cargo check` does not share the build cache with `cargo build`. This causes additional compilation to happen when you run e.g. `cargo check` several times to find all type errors, and when it succeeds, you follow up with `cargo build` to actually produce a built artifact. This workflow is an example of competing trade-offs, because sharing the build cache between these two commands by unifying them more would likely make `cargo check` itself slightly slower, which might be undesirable to some users. It is possible that we might be able to find some middle ground to improve the status quo though. You can follow updates to this work in [this issue][cargo-check-build-reuse-issue].
156
156
157
-
A related aspect is the latency of type checking in code editors and IDEs. Around 87% of respondents say that they use inline annotations in their editor as the primary mechanism of inspecting compiler errors, and around 30% of respondents consider waiting for these annotations to be a big blocker. In the open answers, we also received many reports of Rust Analyzer's performance and memory usage being a limiting factor.
157
+
A related aspect is the latency of type checking in code editors and IDEs. Around 87% of respondents say that they use inline annotations in their editor as the primary mechanism of inspecting compiler errors, and around 33% of them consider waiting for these annotations to be a big blocker. In the open answers, we also received many reports of Rust Analyzer's performance and memory usage being a limiting factor.
158
158
159
159
The maintainers of Rust Analyzer are working hard on improving its performance. Its caching system is [being improved][ra-talk-rustweek] to reduce analysis latency, the distributed builds of the editor are now [optimized with PGO][ra-pgo], which provided 15-20% performance wins, and work is underway to integrate the compiler's [new trait solver][ra-new-trait-solver] into Rust Analyzer, which could eventually also result in increased performance.
160
160
@@ -236,7 +236,7 @@ Build performance of Rust is affected by many different aspects, including the c
236
236
</div>
237
237
<!-- Chart compile-time-improvement-mechanisms end -->
238
238
239
-
It seems that the most popular (and effective) mechanisms for improving build performance are reducing the number of dependencies and their activated features, and splitting larger crates into smaller crates. The most common way of improving build performance without making source code changes seems to be the usage of an alternative linker. It seems that especially the `mold` and `lld` linkers are very popular:
239
+
It seems that the most popular (and effective) mechanisms for improving build performance are reducing the number of dependencies and their activated features, and splitting larger crates into smaller crates. The most common way of improving build performance without making source code changes seems to be the usage of an alternative linker. It seems that especially the mold and LLD linkers are very popular:
240
240
241
241
<!-- Chart alternative-linker start -->
242
242
<div>
@@ -249,7 +249,7 @@ It seems that the most popular (and effective) mechanisms for improving build pe
249
249
</div>
250
250
<!-- Chart alternative-linker end -->
251
251
252
-
We have good news here! After many years, we have finally switched the most popular `x86_64-unknown-linux-gnu` Linux target to use the `lld` linker, resulting in faster link times *by default*. Over time, we will be able to evaluate how disruptive is this change to the overall Rust ecosystem, and whether we could e.g. switch to a different (even faster) linker.
252
+
We have good news here! The most popular `x86_64-unknown-linux-gnu` Linux target will start using the LLD linker in the next Rust stable release, resulting in faster link times *by default*. Over time, we will be able to evaluate how disruptive is this change to the overall Rust ecosystem, and whether we could e.g. switch to a different (even faster) linker.
253
253
254
254
### Build performance guide
255
255
@@ -290,12 +290,13 @@ There are more interesting things in the survey results, for example how do answ
290
290
291
291
We would like to thank once more everyone who has participated in our survey. It helped us understand which workflows are the most painful for Rust developers, and especially the open answers provided several great suggestions that we tried to act upon.
292
292
293
-
Even though the Rust compiler is getting increasingly faster every year, we understand that many Rust developers require truly significant improvements to improve their productivity, rather than "just" incremental performance wins. Our goal for the future is to finally stabilize long-standing initiatives that could improve build performance a lot, such as the [Cranelift codegen backend][project-goal-cranelift] or the [parallel compiler frontend][project-goal-parallel-frontend]. One such initiative (using a [faster linker by default][rust-lld-blog-post]) has finally landed recently, but the fact that it took many years shows how difficult it is to make such large cutting changes to the compilation process.
293
+
Even though the Rust compiler is getting increasingly faster every year, we understand that many Rust developers require truly significant improvements to improve their productivity, rather than "just" incremental performance wins. Our goal for the future is to finally stabilize long-standing initiatives that could improve build performance a lot, such as the [Cranelift codegen backend][project-goal-cranelift] or the [parallel compiler frontend][project-goal-parallel-frontend]. One such initiative (using a [faster linker by default][rust-lld-blog-post]) will finally land soon, but the fact that it took many years shows how difficult it is to make such large cutting changes to the compilation process.
294
294
295
295
There are other ambitious ideas for reducing (re)build times, such as [avoiding unnecessary workspace rebuilds][project-goal-rdr] or e.g. using some form of [incremental linking][wild], but these will require a lot of work and design discussions.
296
296
297
-
We know that some people are wondering why it takes so much time to achieve progress in improving the build performance of Rust. The answer is relatively simple. These changes require a lot of work, domain knowledge (that takes a relatively long time to acquire) and many discussions and code reviews, and the pool of people that have time and motivation to work on them or review these changes is very limited. Current compiler maintainers and contributors (many of whom work on the compiler as volunteers, without any funding) work very hard to keep up with maintaining the compiler and keeping it working with a high-quality bar that Rust developers expect, across many targets, platforms and operating systems. Introducing large structural changes, which are likely needed to reach massive performance improvements, would require a lot of concentrated effort and funding.
297
+
We know that some people are wondering why it takes so much time to achieve progress in improving the build performance of Rust. The answer is relatively simple. These changes require a lot of work, domain knowledge (that takes a relatively long time to acquire) and many discussions and code reviews, and the pool of people that have time and motivation to work on them or review these changes is very limited. Current compiler maintainers and contributors (many of whom work on the compiler as volunteers, without any funding) work very hard to keep up with maintaining the compiler and keeping it working with the high-quality bar that Rust developers expect, across many targets, platforms and operating systems. Introducing large structural changes, which are likely needed to reach massive performance improvements, would require a lot of concentrated effort and funding.
0 commit comments