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
Copy file name to clipboardExpand all lines: content/rust-compiler-performance-survey-2025-results/index.md
+9-5Lines changed: 9 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -158,13 +158,15 @@ A related aspect is the latency of type checking in code editors and IDEs. Aroun
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
161
-
More than 35% users said that they consider the IDE and Cargo blocking one another to be a big problem. There is an existing workaround for this, where you can configure Rust Analyzer to use a different target directory than Cargo, at the cost of increased disk space usage. We realized that this workaround has not been documented in a very visible way, so we added it to the [FAQ section][ra-cargo-blocking] of the Rust Analyzer book.
161
+
More than 35% users said that they consider the IDE and Cargo [blocking one another][ra-cargo-blocking-issue] to be a big problem. There is an existing workaround for this, where you can configure Rust Analyzer to use a different target directory than Cargo, at the cost of increased disk space usage. We realized that this workaround has not been documented in a very visible way, so we added it to the [FAQ section][ra-cargo-blocking-faq] of the Rust Analyzer book.
162
162
163
163
### Clean and CI builds
164
164
165
165
Around 20% of participants responded that clean builds are a significant blocker for them. In order to improve their performance, you can try a recently introduced experimental Cargo and compiler option called [`hint-mostly-unused`][hint-mostly-unused], which can in certain situations help improve the performance of clean builds, particularly if your dependencies contain a lot of code that might not actually be used by your crate(s).
166
166
167
-
One area where clean builds might happen often is Continuous Integration (CI). 1495 respondents said that they use CI to build Rust code, and around 25% of them consider its performance to be a big blocker for them. However, almost 36% of respondents who consider CI build performace to be a big issue said that they do not use any caching in CI, which we found surprising. One explanation might be that the generated artifacts (the `target` directory) is too large for effective caching, and runs into usage limits of CI providers, which is something that we saw mentioned repeatedly in the open answers section. We have recently introduced an experimental Cargo and compiler option called [`-Zembed-metadata`][cargo-no-embed-metadata] that is designed to reduce the size of the `target` directory, which might help with this issue somewhat in the future.
167
+
One area where clean builds might happen often is Continuous Integration (CI). 1495 respondents said that they use CI to build Rust code, and around 25% of them consider its performance to be a big blocker for them. However, almost 36% of respondents who consider CI build performace to be a big issue said that they do not use any caching in CI, which we found surprising. One explanation might be that the generated artifacts (the `target` directory) is too large for effective caching, and runs into usage limits of CI providers, which is something that we saw mentioned repeatedly in the open answers section. We have recently introduced an experimental Cargo and compiler option called [`-Zembed-metadata`][cargo-no-embed-metadata] that is designed to reduce the size of the `target` directories, and work is also underway to regularly [garbage collect][cargo-garbage-collect] them. This might help with the disk space usage issue somewhat in the future.
168
+
169
+
One additional way to significantly reduce disk usage is to reduce the amount of generated debug information, which brings us to the next section.
168
170
169
171
## Debug information
170
172
@@ -185,11 +187,11 @@ However, if Rust developers debug their code after most builds, then this cost m
185
187
</div>
186
188
<!-- Chart debugger end -->
187
189
188
-
Based on these results, it seems that the respondents of our survey do not actually use a debugger all that much[^why-not-debug]. Similarly, only 6% of respondents answered that they use a profiler (which also benefits from at least basic debuginfo) often.
190
+
Based on these results, it seems that the respondents of our survey do not actually use a debugger all that much[^why-not-debug].
189
191
190
192
[^why-not-debug]: Potentially because of the strong invariants upheld by the Rust type system, and partly also because the Rust debugging experience might not be optimal for many users, which is a feedback that we received in the [State of Rust 2024 survey][state-of-rust-2024].
191
193
192
-
On the other hand, when we asked people if they require debuginfo to be generated by default, the responses were much less clear-cut:
194
+
However, when we asked people if they require debuginfo to be generated by default, the responses were much less clear-cut:
193
195
194
196
<!-- Chart required-debuginfo start -->
195
197
<div>
@@ -304,6 +306,7 @@ We know that some people are wondering why it takes so much time to achieve prog
0 commit comments