Comment by jplusequalt
2 days ago
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
2 days ago
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives.
Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take.
On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was.
[0] https://github.com/getsentry/symbolicator
[1] https://github.com/buildkite/agent
Thanks for actually including the slow repo in your comment. My results on a Ryzen 5900X:
* Clean debug build: 1m 22s
* Incremental debug build: 13s
* Clean release build: 1m 51s
* Incremental release build: 24s
Incremental builds were done by changing one line in creates/symbolicator/src/cli.rs.
It's not great, but it sounds like your experience was much worse for some reason.
For reference, buildkite-agent [0] is about 40k lines of go. Running `go build` including dependencies took 40 seconds, and running `go clean && go build` took 2 seconds. I know Go and Rust aren't comparable, but Rust's attitude appears to be "we don't really care" when you compare it to Go, considering they both started at _roughly_ the same time and Rust's first stable release came long after Go was in use.
[0] https://github.com/buildkite/agent
Sorry - my clean build was actually including the dependency fetching, which is a large part of it. My experience was in 2023 which if we go by article roughly scales with compiler performance to 5 minutes or so
3 replies →
> clean build of a few thousand lines of rust took close to 10 minutes
That doesn't sound likely. I would expect seconds unless something very odd is happing.
Is the example symbolicator?
I can't build the optional "symbolicator-crash" crate because it's not rust but 300k of C++/C pulled from a git submodule that requires dependencies I am not going to install. Your complaint might literally be about C++!
For the rest of the workspace, 60k of rust builds in 60 seconds
- clean debug build on a 6 year old 3900X (which is under load because I am working)
- time includes fetching 650 deps over a poor network and building them (the real line count of the build is likely 100s of thousands or millions of lines of code)
- subsequent release build took 100s
- I use the mold linker which is advised for faster builds
- modern cpus are so much faster than my machine they might not even take 10s
> That doesn't sound likely. I would expect seconds unless something very odd is happing.
And yet here we are.
There are plenty of stories like this floating around of degenerate cases of small projects. Here's [0] one example with numbers and how they solved it. There are enough of these issues that by getting bogged down in "well technically it's not Rust's fault, it's LLVM's single threadedness causing the slowdown here" ignores the point - Rust (very fairly) has a rep for being dog slow to compile even compared to large C++ projects
> For the rest of the workspace, 60k of rust builds in 60 seconds
That's... not fast.
https://github.com/buildkite/agent is 40k lines of go according to cloc, and running `go build` including pulling dependencies takes 40 seconds. Without pulling dependencies it's 2 seconds. _That's_ fast.
[0] https://www.feldera.com/blog/cutting-down-rust-compile-times...
Just curious, are you still able to get instant feedback and development conveniences on that 30 minute compile time project, like up to date autocomplete and type hints and real-time errors/warnings while developing before compiling?
Yeah - there’s a 60-ish second delay in my IDE before this info is available but once it’s there it’s there.
Can you say what your development environment was like? I was having 15 minute build times for a pretty small system. Everyone talks about how slow Rust compile times are so I thought that's just how it is. Then, by chance, I ended up building from a clean install on my work laptop and it took about 3 minutes from scratch.
My development environment is VS Code running in a Dev container in docker desktop. So after my work laptop was so fast, I made some changes to my Mac docker desktop and suddenly the mac could build the project from scratch in about 2 minutes. Incremental compile was several minutes before, instant now.
Cargo in vscode on windows on a monstrously big machine (3990x/128GB RAM/NVMe drive, Gigabit Ethernet)
I think if it's that sensitive to environment issues, that solidifies the point that there are major problems that lots of people are going to have.
Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).
I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust
5 replies →
30 minutes versus 60 is really an hour versus two.
Some coworkers and I noticed a long time ago that once you try to task switch while doing build/test automation steps, it always seems like you remember to come back and check about twice as long as the compile was supposed to take. 7+ turned into 15, 15 into a half hour.
And then one day it hit me that this is just Hofstadter’s Law. You think you have ten minutes so you start a ten minute task and it takes you twenty, or you get in a flow and forget to look until your senses tell you you’re forgetting something.
Cutting 10 minutes off a build really averages 20 minutes in saved time per cycle. Which matters a hell of a lot when you go from 4 to 5 cycles per 8 hour day.
What are incremental compile times with the C++ codebase?
Also, does the line of code you count include dependencies (admitting, dependencies in Rust are a problem, but it's not related to compiler performance)?
About 15 seconds, because we carve it up into 100 or so dlls specifically for this case
2 replies →
>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust
I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness.
When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.
Makes sense to me! Everyone with enough C++ experience has dealt with that nightmare at one point. Never again, if you can help it.
It is a quantifiable negative to which you can always point. Of course it will be used for justifications.
There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.
You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize.
To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
There are things you can do for Rust if it really is a deal breaker.
Dioxus has a hot reload system. Some rust game engines have done similar things.
When in doubt, manually patch your dll's
The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.
> Avoiding template heavy pigs like QT
Well, you definitely have no experience with Qt.
C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest.
* It's not beating interpreted languages any time soon, but that's not really a fair comparison.