Empowering everyone to build reliable and efficient software.
I think it helps to have some of the not-exactly-stated background: their build did not originally take 2mn, it suddenly shot up to this from around 20s seemingly overnight, so they investigated what happened, and as that's lime they also produced a nice article out of it.
That's my assumption anyway because that's about what I went through, minus the blog post: had a project I was working on, at one point I noticed the clean builds were getting really long, we're talking >10mn. Initially I figured it might be Serde (as that project is really serde-heavy) and the compile time had crept up on me unnoticed, so I moved all the serialized and deserialized types in a sub-crate in case that did anything... and it did not.
Then I busted out the -Ztimings getting about the same result Lime did (ungodly amount of time spent producing the binary for no clear reason), tried fiddling with some compile-time options (went nowhere near as deep there, I looked at -Z self-profile fairly quickly IIRC), finally found the evaluate_obligation stuff. From there I didn't bust out the profiler to see what was what, instead through I don't quite remember which chain got me to issue 91598 (https://github.com/rust-lang/rust/issues/91598).
Added a follow to the issue and various PRs proposed for it, and locked the project to 1.56.
Rust for Windows
I feel the same pain, specially since when using C++ I tend to just use binary libraries for all the code I don't own, so even cold builds are quite fast even when talking about C++.
Just by having cargo support binary libraries would be an improvement for cold builds, but I understand it isn't a priority.
The Rust/WinRT folks have a big binary crate that they use to workaround Rust's compilation times, https://github.com/microsoft/windows-rs/tree/master/.windows
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
Website for graphing performance of rustc
We track performance: https://perf.rust-lang.org/
I assure you it's not an afterthought. We track performance changes every week, going as far as reverting highly desired features to avoid regressions. The only reason we accept (small) regressions is for correctness fixes. This regression was only partly exercised by our perf test suite. That's how we grow it: see bad behaviour in the wild, add to the suite.
The source of rust compilation slowness usually boil down to excercising a part of the language that has O(n²) behaviour, like match arm evaluation, trait bound evaluation, or huge expansion due to monomorphization or macro expansion, and the resulting huge linking times from that, or the bottleneck that proc-macros introduce (they get compiled before they can get executed, only relevant on fresh compiles).
The regression was (partly) fixed by adding caching: https://github.com/rust-lang/rust/pull/90423/files and if I recall correctly was introduced by a feature change that fixed a bunch of incorrectly rejected deeply nested trait bounds.
Apache Maven Daemon
Use Maven Daemon. (https://github.com/apache/maven-mvnd) . With Maven Daemon, traditional maven builds get a spectacular boost factor that put them ahead of Gradle. (Haven't tried Bazel though)
The Rust package manager
Rust 1.56.0 and Rust 2021
5 projects | news.ycombinator.com | 21 Oct 2021
Announcing Rust 1.61.0
6 projects | reddit.com/r/rust | 19 May 2022
4 projects | dev.to | 30 Apr 2022
Announcing Rust 1.60.0
4 projects | reddit.com/r/rust | 7 Apr 2022
Rust 1.60 released
2 projects | reddit.com/r/rust | 7 Apr 2022