Probably the most common complaint about Rust is its slow feedback loop and long compilation times. I hear and read about this constantly: in Rust podcasts, blog posts , surveys , conference talks, and offline discussions. As a Rust user myself, I regularly complain about this!
Furthermore, along with the usual complaints about compile times, I've started seeing similar statements from frustrated Rust developers: "Why isn't the Rust Project addressing this important and obvious issue more actively? Why isn't something being done about it?" I'm a member of the Rust Compiler Performance Working Group , so I take these questions very seriously. And, of course, I have an opinion on the matter. In this post, I'll share my thoughts, which may serve as answers to these (and similar) questions.
And all this effort is paying off: Rust build performance has improved significantly over the past few years! When discussing long-term trends, we usually show a dashboard , but I find it a bit dry because it averages the results of many benchmarks, and these benchmarks are quite short, so their results become increasingly less meaningful. Instead, I ran a small experiment to show how performance has evolved on my favorite test case, hyperqueue . I took its first commit (from March 2021) and compiled it with several versions of the Rust compiler, spaced about a year apart. [I chose an old commit so that it could be compiled even with older versions rustc. Luckily, I have all the stable versions of the compiler downloaded from my recent compiler bug experiment .] The tests were run on a relatively average 8-core AMD laptop running Linux. Here are the results:
[TH]
[TR]
[TD]
[TD]
[TD]
[TD]
[/TR]
[TR]
[TD]
[TD]
[TD]
[TD]
[/TR]
[TR]
[TD]
[TD]
[TD]
[TD]
[/TR]
[TR]
[TD]
[TD]
[TD]
[TD]
[/TR]
In this benchmark, the compiler is almost twice as fast as it was three years ago. Of course, this is just one example; in other cases, the speedup will be higher or lower. It will likely also be lower overall on all platforms except Linux x64, as we focus our efforts on optimizing for that specific platform. However, it must be acknowledged that compiler performance is steadily improving.
Before we delve into the problem in more detail, I think it's worth considering whether it's fundamentally solvable, and what goal we ultimately want to achieve. Can Rust, with its complex type system, borrow checking, monomorphization, proc macros and build scripts, large translation units, machine code generation, and "rebuild the world from source" compilation model, even hope to achieve near-instantaneous (re-)build times? After all, in the past, it has favored runtime (over compilation) performance at almost every opportunity ?
I think it depends on the use case. If we're talking about building projects with hundreds of dependencies from scratch or creating highly optimized LTO builds, I don't think we'll ever achieve truly instantaneous speed. On the other hand, I personally believe (though some may disagree!) that there's no fundamental limitation preventing the Rust compiler from being able to rebuild a Rust project of almost any size almost instantly in incremental (and at least slightly optimized) mode after making small changes to the source code, where the rebuild time is O(количество внесённых изменений), not O(размер кодовой базы). Tradeoffs could probably be made, such as sacrificing runtime performance, but I believe this goal is achievable. In fact, we even have examples of achieving something similar today (though in fairly limited scenarios)!
And I won't say we don't have ideas on how to achieve this goal (or at least get closer to it). There are many approaches to speeding up the compilation process in various ways, such as a parallel frontend , alternative code generation backends , using a faster linker by default , deferred generation ( MIR-only rlib , -Zhint-mostly-unused ), avoiding useless workspace rebuilds , smarter incremental compilation (including incremental linking or even hot-patching of binaries), and much more.
Some of these approaches aren't ready for widespread use yet, but others can be implemented today. They usually help (but not always). I believe that if we had a magic wand and could implement all of these changes today, we would achieve very fast incremental builds in a large (much larger) share of Rust projects.
And it's not just the Rust community as a whole that will benefit. Improving build performance will also increase the productivity of contributors to the Rust toolchain. It reduces the time needed to rebuild the compiler itself when changes are made, speeds up our CI processes, reduces the wait time for tests and compiler performance benchmarks… Everyone benefits! So what's stopping us from moving faster?Why aren't we doing something about it?! [Sorry, I couldn't resist.]
, as probably other large (compiler) codebases do, and although we have a contribution guide , analyzing what's going on still takes time. [The compiler consists of approximately six hundred thousand lines of Rust code, and the standard library is similar in size.] In fact, there's probably no one who fully understands the compiler codebase (with the possible exception of compiler-errors ).
While it's possible to improve performance without a deep understanding of the compiler (using profiling and micro-optimizations in various parts), this approach has its limitations, and the simplest solutions have already been implemented. [However, not all of them. See this recent brilliant PR . ] Various benchmarks and use cases have been optimized to achieve a "local minimum performance," so even when improvements are made in some use cases, regressions occur elsewhere, which can lead to the localized improvement being abandoned.
When deciding whether to implement specific performance optimizations, we also need to consider various tradeoffs. For example, we know tricks that can slightly speed up the compiler on Linux x64 (the most popular target platform). We can compile rustc with support for "new" instruction architectures, such as AVX256, which seems to provide some benefits . However, this will cause the compiler to stop working on older x64 CPUs, which we still officially support ! Or we could use a different memory allocator (such as mimalloc ), which also seems to provide a modest performance boost , but at the cost of increased memory usage , which can lead to OOMs rustc on devices with limited RAM. You might be thinking: why not release several different versions of the compiler (for the same target platform) with different optimizations, allowing developers (or rustup) to choose the one that suits them best? Building the most optimized compiler variant for Linux already requires a huge amount of CI resources, not to mention that distributing the toolchain in multiple variants will significantly increase the amount of data transferred to users over the network, which is already enormous. The pros and cons of each approach need to be considered.
I believe there are two main paths to achieving truly significant build performance gains. The first, which I believe is very promising, is improving specific compilation processes. We don't necessarily need to speed up the entire compiler if we can significantly improve the performance (or reduce the amount of work required) of specific processes that currently significantly limit the productivity of a large percentage of Rust developers. An example of this is the Relink, don't rebuild proposal , which has the potential to reduce the amount of compilation required when changing a crate in a large Cargo workspace. Solutions like these won't necessarily speed up the compiler itself, but they will make the compilation process smarter, and this is an area where rustc significant improvements can be made. Many of these potential process improvements aren't always strictly related to the compiler itself, but can also be found at the intersection rustc of the build system being used (most often, Cargo).
I hope that some of these ideas will significantly speed up Rust compilation processes in the near future without requiring major changes to the compiler implementation. However, even such targeted optimizations are not easy to implement. Achieving impressive performance for a proof-of-concept is the "easiest" part. But beyond that comes a long tail of very difficult work—ensuring that the change covers all edge cases and specifics of the Rust compilation process, works on all target platforms, avoids regressions in important use cases and benchmarks, ensures ease of maintenance, ensures backward compatibility, and so on.
The second option, as you might have guessed, is to... make significant changes and/or refactor the compiler implementation. However, this is, of course, a complex task for a number of reasons. First, we need to align the overall thinking with the rest of the compiler team using a Major Change Proposal so that the other compiler maintainers will accept such a significant change. Then, obviously, we need to implement these changes, which requires a lot of effort. For example, if we change one element in the "bottom" layer of the compiler, we'll have to fix hundreds of different places, as well as potentially numerous test cases, and that's a very time-consuming process. [If you're wondering "why can't AI do this?", the answer is that it could probably help with a lot of things in this area, but differences in compiler diagnostics (which remains a big part of what our test suite checks) often come down to subjective decisions that we (fortunately) still leave to humans to make.] You'll also have to find a reviewer with the resources to approve the changes, and that process can take many PRs and weeks, months, or even years.
Making large, cross-cutting changes is also a challenging process, as they will inevitably conflict with numerous other changes being made to the compiler simultaneously. You can try to make the changes outside the main compiler tree, but this is almost certainly doomed to failure given the rate at which the compiler changes. [On average, we merge about 25-30 PRs per day .] Or you can try to incorporate the changes in one huge PR, which can lead to endless rebases (and make it difficult to find a reviewer). Or you'll have to migrate incrementally, which can require lengthy (and possibly tedious) maintenance of two separate implementations of the same feature.
An example of a major internal change (though not directly related to performance ) is the reimplementation of the compiler's trait solver . Although very smart and experienced people are working on it, it took many years to complete . This is precisely the scale of the change we'll have to deal with if we want to carry out such a major refactoring of the compiler's internals. This is worth keeping in mind for people asking when we'll finally rewrite the entire compiler in the Data-Oriented Design paradigm to make it a billion times faster.
Speaking of DOD, it's also worth considering the maintainability of the compiler's codebase. Imagine if we waved a magic wand and rewrote everything overnight using DOD, SIMD vectorization, hand-unrolled assembler, and so on. The compiler would likely become several times faster. Hooray! However, we're concerned not only with immediate performance but also with long-term improvements. Improving performance with code that's difficult to develop, understand, debug, and maintain would be a disservice to us. Hundreds of volunteers work on the compiler, so we want the codebase to remain understandable to them (at least partially). Therefore, long-term maintainability of the codebase should also be considered.
The challenges described above are quite real, but certainly not unique to rustc. It's probably no surprise that introducing major changes to a large codebase (of a compiler) is a complex process. I'm sure the GCC/LLVM/Clang maintainers also have many ideas for improving or speeding up these projects, but implementing them will require significant effort and time. But there are other reasons why compiler performance isn't the only thing that matters to us.
The Rust compiler is very stable and reliable (at least in my opinion), and you can count on new versions being released every six months. And that's not easy! And you shouldn't take it for granted. You can't just start with a working state and do nothing. A lot of time is spent ensuring stability, keeping the infrastructure and CI running, fixing particularly serious bugs in a timely manner, reviewing incoming issues, maintaining backward compatibility, reviewing PRs, quickly fixing security issues, keeping external dependencies like LLVM up to date, and much more. And all of this must work on all supported target platforms ! Currently, there are 8 critical platforms (for which a build must be performed and all tests must pass) and 91 (!) second-tier platforms (for which a build must at least occur). This work is largely done by volunteers who care deeply about Rust and its toolchain and want to continue to ensure its functionality. This requires a lot of work in Rust. [I like to say that if you give us a hundred full-time engineers, I'll instantly find something for them to do in the Rust toolchain.]
And all this work, of course, eats up time that could have been spent, for example, speeding up the compiler. If you don't think this work is that important, ask yourself whether you'd be happy with a compiler that's twice as fast but occasionally compiles incorrectly.
It's also worth considering that new features are constantly being added to the language and compiler: new compiler flags to support projects like Rust for Linux , syntactic improvements , complex language features , and much more. Overall, the language is far from "finished," so many aspects are still under development; there are nearly two hundred open pull requests (RFCs) and many more being accepted that haven't yet been implemented and stabilized. At any given time, we have about seven hundred open PRs in the main Rust repository, and over ten thousand open issues , so activity is high.
And it seems Rust users want it to evolve at the same rate or even faster, meaning even more changes are on the way! Have you ever thought, "I wish this little feature X would finally stabilize" so your code would be better? It's perfectly normal to want new features from a language, but we mustn't forget that this requires a lot of experimentation, bug fixing, testing, and implementation work, which also takes time away from performance optimization. Not to mention that adding new features usually slightly reduces compiler performance because it has to do more work.
However, there are certain ways to ensure the conditions for work on compiler performance. The Rust Project now has a Project Goals program , defining a set of goals and projects that we consider important. We welcome contributions (with the promise of review and support) in these areas. In the near future, I'll try to make compiler performance one of my top goals, because I believe it deserves it. This will likely help motivate more people to work on it.
And while it may sound a bit trivial, accelerating progress is a matter of funding (at least in part). I sometimes hear complaints that some projects aimed at improving compiler performance take too long to implement. It's as if they expect a full team of well-paid engineers to work on these projects. It's worth remembering that the Rust Project is still largely made up of volunteers, and that many people contribute to it in their free time. Many improvements to Rust (including important compiler performance improvements) were literally made possible by a single university student working tirelessly every day to improve Rust, often without any pay. Their progress may be slowed (for example) by exams or a paid job that allows them to pay for housing and food.
At the recent RustWeek conference and the associated All Hands event, I saw growing interest from various companies looking to invest in improving the performance of the Rust compiler. And that's great! Improving performance rustc requires long-term, focused effort, and providing stable funding to contributors is one way to accelerate progress. However, it's important to understand that making improvements isn't just about working on the implementation: someone needs to review it and maintain it in the future. In an ideal world, companies would fund long-term compiler support, rather than paying their employees to implement the optimizations they need and then disappear. Sometimes the best way to help advance a particular area of Rust isn't by implementing it, but by accumulating knowledge, becoming an expert in a particular area of the compiler, and helping review other people's code to free them up to do their own work. But, of course, this requires long-term investment.
In my experience, interest in compiler performance work among Rust compiler contributors is poorly correlated with the volume of online discussions on the topic (and that's perfectly fine!). If I could use my magic wand again and convince more contributors to take an interest in this, would I do it? Probably. Would it benefit Rust in the long run? I don't know! For now, language and compiler development seem to be going well, and who am I to set priorities? I trust the project contributors and believe that collectively they are doing what's best for Rust, both today and in the future.
I find it interesting that many people would likely be focusing on performance improvements if they weren't juggling so much work at once. For example, when I started contributing to Rust in 2021, I was primarily interested in compiler performance. So I focused on optimization. Then I noticed that it would be useful to work on a set of compiler benchmarks , so I worked on that. Then I noticed that we weren't compiling the compiler itself with all possible optimizations, so I started adding LTO/PGO/BOLT support , which subsequently led to improvements to the CI infrastructure. Then I noticed that we were waiting a long time for CI processes to complete, so I focused on optimizing them . Then I moved on to the annual Rust survey , then the GSoC program , then improving bors , then… Many of these efforts indirectly impacted compiler performance (at least, I hope so), either by reducing the burden on other contributors or by improving the infrastructure (in various senses of the word). However, only now, after several years of constantly drifting away from my main goal, am I finally trying to return to direct work on compiler performance.
In other words, the more help we can get with Rust maintenance (regardless of the specific area!), the more likely it is that we will collectively have more time to spend improving the compiler's performance.
Regarding future compiler performance improvements, I'm looking forward to the various initiatives discussed at the All Hands events, as well as LLD becoming the default linker on Linux (hopefully in the coming months). I'm also planning to conduct a compiler performance survey soon to understand which processes are bottlenecks for Rust users, and I want to improve the profiling infrastructure for what the compiler actually does during compilation.
I hope this post will help you understand why improving build performance isn't such a simple task. If you'd like to join the team, I'd love to see you !
Furthermore, along with the usual complaints about compile times, I've started seeing similar statements from frustrated Rust developers: "Why isn't the Rust Project addressing this important and obvious issue more actively? Why isn't something being done about it?" I'm a member of the Rust Compiler Performance Working Group , so I take these questions very seriously. And, of course, I have an opinion on the matter. In this post, I'll share my thoughts, which may serve as answers to these (and similar) questions.
Do we even care?
First, I must assure you that yes, we (that is, the Rust Project) are absolutely concerned about the performance of our beloved compiler, and we are putting a lot of work into improving it. We evaluate performance improvements and regressions every week. We conduct thorough benchmarking after every merged PR. We happily accept any performance improvements (as long as they don't force difficult tradeoffs; more on that below) and try to quickly roll back (or fix) PRs that cause performance regressions. Very smart people are constantly working to find bottlenecks and speed up the compiler . And work is already underway to implement significant improvements to improve compilation speed.And all this effort is paying off: Rust build performance has improved significantly over the past few years! When discussing long-term trends, we usually show a dashboard , but I find it a bit dry because it averages the results of many benchmarks, and these benchmarks are quite short, so their results become increasingly less meaningful. Instead, I ran a small experiment to show how performance has evolved on my favorite test case, hyperqueue . I took its first commit (from March 2021) and compiled it with several versions of the Rust compiler, spaced about a year apart. [I chose an old commit so that it could be compiled even with older versions rustc. Luckily, I have all the stable versions of the compiler downloaded from my recent compiler bug experiment .] The tests were run on a relatively average 8-core AMD laptop running Linux. Here are the results:
Versionrustc | Clean build [c] | Incremental rebuild |
|---|
[TH]
Speed increase (clean build)
[/TH][TR]
[TD]
1.61.0 (May 2022)
[/TD][TD]
26.1 s
[/TD][TD]
~0.39
[/TD][TD]
-
[/TD][/TR]
[TR]
[TD]
1.70.0 (June 2023)
[/TD][TD]
20.2 s
[/TD][TD]
~0.37
[/TD][TD]
x1.29
[/TD][/TR]
[TR]
[TD]
1.78.0 (May 2024)
[/TD][TD]
17.0 s
[/TD][TD]
~0.30
[/TD][TD]
x1.53
[/TD][/TR]
[TR]
[TD]
1.87.0 (May 2025)
[/TD][TD]
14.7 s
[/TD][TD]
~0.26
[/TD][TD]
x1.77
[/TD][/TR]
In this benchmark, the compiler is almost twice as fast as it was three years ago. Of course, this is just one example; in other cases, the speedup will be higher or lower. It will likely also be lower overall on all platforms except Linux x64, as we focus our efforts on optimizing for that specific platform. However, it must be acknowledged that compiler performance is steadily improving.
But it's still not fast enough.
All of this is great, of course, but it doesn't change the fact that for many Rust developers, compilation performance remains a serious bottleneck; they would be much more productive if the feedback loop were an order of magnitude faster. Frankly, it depends on whose opinion you ask: for example, some C++ developers don't have any complaints about Rust's compilation times because they're used to similar (or even longer) compilation times; Python programmers, on the other hand, are likely unimpressed by the speed of Rust's feedback loop. But it's almost certain that many users today feel that Rust's compilation speed isn't fast enough , and that's a problem.Before we delve into the problem in more detail, I think it's worth considering whether it's fundamentally solvable, and what goal we ultimately want to achieve. Can Rust, with its complex type system, borrow checking, monomorphization, proc macros and build scripts, large translation units, machine code generation, and "rebuild the world from source" compilation model, even hope to achieve near-instantaneous (re-)build times? After all, in the past, it has favored runtime (over compilation) performance at almost every opportunity ?
I think it depends on the use case. If we're talking about building projects with hundreds of dependencies from scratch or creating highly optimized LTO builds, I don't think we'll ever achieve truly instantaneous speed. On the other hand, I personally believe (though some may disagree!) that there's no fundamental limitation preventing the Rust compiler from being able to rebuild a Rust project of almost any size almost instantly in incremental (and at least slightly optimized) mode after making small changes to the source code, where the rebuild time is O(количество внесённых изменений), not O(размер кодовой базы). Tradeoffs could probably be made, such as sacrificing runtime performance, but I believe this goal is achievable. In fact, we even have examples of achieving something similar today (though in fairly limited scenarios)!
And I won't say we don't have ideas on how to achieve this goal (or at least get closer to it). There are many approaches to speeding up the compilation process in various ways, such as a parallel frontend , alternative code generation backends , using a faster linker by default , deferred generation ( MIR-only rlib , -Zhint-mostly-unused ), avoiding useless workspace rebuilds , smarter incremental compilation (including incremental linking or even hot-patching of binaries), and much more.
Some of these approaches aren't ready for widespread use yet, but others can be implemented today. They usually help (but not always). I believe that if we had a magic wand and could implement all of these changes today, we would achieve very fast incremental builds in a large (much larger) share of Rust projects.
And it's not just the Rust community as a whole that will benefit. Improving build performance will also increase the productivity of contributors to the Rust toolchain. It reduces the time needed to rebuild the compiler itself when changes are made, speeds up our CI processes, reduces the wait time for tests and compiler performance benchmarks… Everyone benefits! So what's stopping us from moving faster?
So why aren't we doing more?
This is a complex question with no clear answer. Based on my personal experience with the Rust Project, I'll try to list various reasons (in no particular order) why we're not moving faster.Technical reasons
Let's start with the technical reasons, which are the easiest to understand. Making non-trivial performance improvements to the Rust compiler is a difficult task! It has a large codebase with a fair amount of technical debtWhile it's possible to improve performance without a deep understanding of the compiler (using profiling and micro-optimizations in various parts), this approach has its limitations, and the simplest solutions have already been implemented. [However, not all of them. See this recent brilliant PR . ] Various benchmarks and use cases have been optimized to achieve a "local minimum performance," so even when improvements are made in some use cases, regressions occur elsewhere, which can lead to the localized improvement being abandoned.
When deciding whether to implement specific performance optimizations, we also need to consider various tradeoffs. For example, we know tricks that can slightly speed up the compiler on Linux x64 (the most popular target platform). We can compile rustc with support for "new" instruction architectures, such as AVX256, which seems to provide some benefits . However, this will cause the compiler to stop working on older x64 CPUs, which we still officially support ! Or we could use a different memory allocator (such as mimalloc ), which also seems to provide a modest performance boost , but at the cost of increased memory usage , which can lead to OOMs rustc on devices with limited RAM. You might be thinking: why not release several different versions of the compiler (for the same target platform) with different optimizations, allowing developers (or rustup) to choose the one that suits them best? Building the most optimized compiler variant for Linux already requires a huge amount of CI resources, not to mention that distributing the toolchain in multiple variants will significantly increase the amount of data transferred to users over the network, which is already enormous. The pros and cons of each approach need to be considered.
I believe there are two main paths to achieving truly significant build performance gains. The first, which I believe is very promising, is improving specific compilation processes. We don't necessarily need to speed up the entire compiler if we can significantly improve the performance (or reduce the amount of work required) of specific processes that currently significantly limit the productivity of a large percentage of Rust developers. An example of this is the Relink, don't rebuild proposal , which has the potential to reduce the amount of compilation required when changing a crate in a large Cargo workspace. Solutions like these won't necessarily speed up the compiler itself, but they will make the compilation process smarter, and this is an area where rustc significant improvements can be made. Many of these potential process improvements aren't always strictly related to the compiler itself, but can also be found at the intersection rustc of the build system being used (most often, Cargo).
I hope that some of these ideas will significantly speed up Rust compilation processes in the near future without requiring major changes to the compiler implementation. However, even such targeted optimizations are not easy to implement. Achieving impressive performance for a proof-of-concept is the "easiest" part. But beyond that comes a long tail of very difficult work—ensuring that the change covers all edge cases and specifics of the Rust compilation process, works on all target platforms, avoids regressions in important use cases and benchmarks, ensures ease of maintenance, ensures backward compatibility, and so on.
The second option, as you might have guessed, is to... make significant changes and/or refactor the compiler implementation. However, this is, of course, a complex task for a number of reasons. First, we need to align the overall thinking with the rest of the compiler team using a Major Change Proposal so that the other compiler maintainers will accept such a significant change. Then, obviously, we need to implement these changes, which requires a lot of effort. For example, if we change one element in the "bottom" layer of the compiler, we'll have to fix hundreds of different places, as well as potentially numerous test cases, and that's a very time-consuming process. [If you're wondering "why can't AI do this?", the answer is that it could probably help with a lot of things in this area, but differences in compiler diagnostics (which remains a big part of what our test suite checks) often come down to subjective decisions that we (fortunately) still leave to humans to make.] You'll also have to find a reviewer with the resources to approve the changes, and that process can take many PRs and weeks, months, or even years.
Making large, cross-cutting changes is also a challenging process, as they will inevitably conflict with numerous other changes being made to the compiler simultaneously. You can try to make the changes outside the main compiler tree, but this is almost certainly doomed to failure given the rate at which the compiler changes. [On average, we merge about 25-30 PRs per day .] Or you can try to incorporate the changes in one huge PR, which can lead to endless rebases (and make it difficult to find a reviewer). Or you'll have to migrate incrementally, which can require lengthy (and possibly tedious) maintenance of two separate implementations of the same feature.
An example of a major internal change (though not directly related to performance ) is the reimplementation of the compiler's trait solver . Although very smart and experienced people are working on it, it took many years to complete . This is precisely the scale of the change we'll have to deal with if we want to carry out such a major refactoring of the compiler's internals. This is worth keeping in mind for people asking when we'll finally rewrite the entire compiler in the Data-Oriented Design paradigm to make it a billion times faster.
Speaking of DOD, it's also worth considering the maintainability of the compiler's codebase. Imagine if we waved a magic wand and rewrote everything overnight using DOD, SIMD vectorization, hand-unrolled assembler, and so on. The compiler would likely become several times faster. Hooray! However, we're concerned not only with immediate performance but also with long-term improvements. Improving performance with code that's difficult to develop, understand, debug, and maintain would be a disservice to us. Hundreds of volunteers work on the compiler, so we want the codebase to remain understandable to them (at least partially). Therefore, long-term maintainability of the codebase should also be considered.
The challenges described above are quite real, but certainly not unique to rustc. It's probably no surprise that introducing major changes to a large codebase (of a compiler) is a complex process. I'm sure the GCC/LLVM/Clang maintainers also have many ideas for improving or speeding up these projects, but implementing them will require significant effort and time. But there are other reasons why compiler performance isn't the only thing that matters to us.
Priorities
While many Rust users seem to want compiler performance to be the Rust Project's top priority, we shouldn't forget about other aspects.The Rust compiler is very stable and reliable (at least in my opinion), and you can count on new versions being released every six months. And that's not easy! And you shouldn't take it for granted. You can't just start with a working state and do nothing. A lot of time is spent ensuring stability, keeping the infrastructure and CI running, fixing particularly serious bugs in a timely manner, reviewing incoming issues, maintaining backward compatibility, reviewing PRs, quickly fixing security issues, keeping external dependencies like LLVM up to date, and much more. And all of this must work on all supported target platforms ! Currently, there are 8 critical platforms (for which a build must be performed and all tests must pass) and 91 (!) second-tier platforms (for which a build must at least occur). This work is largely done by volunteers who care deeply about Rust and its toolchain and want to continue to ensure its functionality. This requires a lot of work in Rust. [I like to say that if you give us a hundred full-time engineers, I'll instantly find something for them to do in the Rust toolchain.]
And all this work, of course, eats up time that could have been spent, for example, speeding up the compiler. If you don't think this work is that important, ask yourself whether you'd be happy with a compiler that's twice as fast but occasionally compiles incorrectly.
It's also worth considering that new features are constantly being added to the language and compiler: new compiler flags to support projects like Rust for Linux , syntactic improvements , complex language features , and much more. Overall, the language is far from "finished," so many aspects are still under development; there are nearly two hundred open pull requests (RFCs) and many more being accepted that haven't yet been implemented and stabilized. At any given time, we have about seven hundred open PRs in the main Rust repository, and over ten thousand open issues , so activity is high.
And it seems Rust users want it to evolve at the same rate or even faster, meaning even more changes are on the way! Have you ever thought, "I wish this little feature X would finally stabilize" so your code would be better? It's perfectly normal to want new features from a language, but we mustn't forget that this requires a lot of experimentation, bug fixing, testing, and implementation work, which also takes time away from performance optimization. Not to mention that adding new features usually slightly reduces compiler performance because it has to do more work.
Contributors
Ultimately, the amount of effort spent on compiler performance optimization depends on the contributors and maintainers. They often work as volunteers and have diverse interests. Some contributors aren't interested in performance optimization at all. And that's perfectly fine! It's important to remember that Rust isn't a company (Mara Bos's excellent post is a must-read!). We don't tell people what to work on, or assign them tasks or tickets. If there aren't people interested in making the compiler faster, then it's likely no one will work on it. It's that simple.However, there are certain ways to ensure the conditions for work on compiler performance. The Rust Project now has a Project Goals program , defining a set of goals and projects that we consider important. We welcome contributions (with the promise of review and support) in these areas. In the near future, I'll try to make compiler performance one of my top goals, because I believe it deserves it. This will likely help motivate more people to work on it.
And while it may sound a bit trivial, accelerating progress is a matter of funding (at least in part). I sometimes hear complaints that some projects aimed at improving compiler performance take too long to implement. It's as if they expect a full team of well-paid engineers to work on these projects. It's worth remembering that the Rust Project is still largely made up of volunteers, and that many people contribute to it in their free time. Many improvements to Rust (including important compiler performance improvements) were literally made possible by a single university student working tirelessly every day to improve Rust, often without any pay. Their progress may be slowed (for example) by exams or a paid job that allows them to pay for housing and food.
At the recent RustWeek conference and the associated All Hands event, I saw growing interest from various companies looking to invest in improving the performance of the Rust compiler. And that's great! Improving performance rustc requires long-term, focused effort, and providing stable funding to contributors is one way to accelerate progress. However, it's important to understand that making improvements isn't just about working on the implementation: someone needs to review it and maintain it in the future. In an ideal world, companies would fund long-term compiler support, rather than paying their employees to implement the optimizations they need and then disappear. Sometimes the best way to help advance a particular area of Rust isn't by implementing it, but by accumulating knowledge, becoming an expert in a particular area of the compiler, and helping review other people's code to free them up to do their own work. But, of course, this requires long-term investment.
In my experience, interest in compiler performance work among Rust compiler contributors is poorly correlated with the volume of online discussions on the topic (and that's perfectly fine!). If I could use my magic wand again and convince more contributors to take an interest in this, would I do it? Probably. Would it benefit Rust in the long run? I don't know! For now, language and compiler development seem to be going well, and who am I to set priorities? I trust the project contributors and believe that collectively they are doing what's best for Rust, both today and in the future.
I find it interesting that many people would likely be focusing on performance improvements if they weren't juggling so much work at once. For example, when I started contributing to Rust in 2021, I was primarily interested in compiler performance. So I focused on optimization. Then I noticed that it would be useful to work on a set of compiler benchmarks , so I worked on that. Then I noticed that we weren't compiling the compiler itself with all possible optimizations, so I started adding LTO/PGO/BOLT support , which subsequently led to improvements to the CI infrastructure. Then I noticed that we were waiting a long time for CI processes to complete, so I focused on optimizing them . Then I moved on to the annual Rust survey , then the GSoC program , then improving bors , then… Many of these efforts indirectly impacted compiler performance (at least, I hope so), either by reducing the burden on other contributors or by improving the infrastructure (in various senses of the word). However, only now, after several years of constantly drifting away from my main goal, am I finally trying to return to direct work on compiler performance.
In other words, the more help we can get with Rust maintenance (regardless of the specific area!), the more likely it is that we will collectively have more time to spend improving the compiler's performance.
Conclusion
It's funny that after writing this post, I realized that you could replace the phrase "compiler performance" with almost anything people want from Rust ("why doesn't Rust have X"), and many of my arguments would still be valid. In this sense, compiler performance isn't anything special, but just one of many (very important!) aspects that we care about and strive to improve.Regarding future compiler performance improvements, I'm looking forward to the various initiatives discussed at the All Hands events, as well as LLD becoming the default linker on Linux (hopefully in the coming months). I'm also planning to conduct a compiler performance survey soon to understand which processes are bottlenecks for Rust users, and I want to improve the profiling infrastructure for what the compiler actually does during compilation.
I hope this post will help you understand why improving build performance isn't such a simple task. If you'd like to join the team, I'd love to see you !
