Hacker News Reader

Comment by baq | Hacker News Reader

How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.

This is absolutely a pain point for us, working on a very large Rust project. In particular, incremental compile times are absolutely critical for developer comfort, and by far the most common complaint working on our codebase is that developer tooling, IDEs and running unit tests is slow. We've done everything that can reasonably be done - splitting the project into crates, using mold as a linker (the single biggest improvement), etc. Without a really big improvement to incremental compile, we will have a continuing drag on our development momentum.

maybe https://github.com/bjorn3/rustc_codegen_cranelift

https://old.reddit.com/r/rust/comments/107afei/cranelift_mol...

I'm curious what are your actual compile times? What does "painfully long" mean for you and your workflow? 15 seconds? 2 minutes? 15 minutes?

This is a bit of a "how long is a piece of string" question. It depends on the developer workstation, which file they're currently working on, etc. That said, we're talking about incremental compile times here, not total project from-scratch compile times. A lag of a few seconds really makes a difference to developer comfort - I'd say, when it's an issue, we're talking about rust-analyzer responsiveness (mainly due to cargo check on save, which can be disabled) of a 3-8 seconds, and delays in running unit tests of 5-20 seconds. I work on a super beefy ThreadRipper monster so I'm less affected, but colleagues on under-powered laptops suffer a lot.

Painfully long to me is everything over 5 seconds.

If you consider how much LLVM instructions are emitted and how much time Rust spends linking, the potential for speedups seems very significant.

Any reasons why it could not be as fast as the Go compiler? Maybe GC and the borrow checker could slow down a bit, but apart from that?

The Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.

In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html...

The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. Rust programs really need the `--release` flag to shine—and in some cases, the dev builds of a program cannot be meaningfully used, even for local testing, since they're so slow.

> The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program.

It could definitely be better, sure.

The reference compiler needs a lot of time to make the resulting binary fast, okay fine. But where's the rust-lang.org group's fork of the golang.org group's `go build` tool modified to accept source files written in the Rust language as input and that (quickly) outputs a binary with a performance profile no faster or slower an equivalent program written in Golang? ~15 years of compiler research is too long and comparisons between the two languages (however fair or un-) are too numerous for there to be any excuse for this not to exist, and yet

Go production build is quite small as much as I can say, but I don't understand much at compilers so I will not discuss this. I've a lot of hands on experience with both Go and Rust, and on mid size project, an incremental production build in Go will take less than 1 second, whereas a development (non release) incremental build in Rust will take 10/15s (something as simple as a `println!` update). It's subjective, but it's not much exaggerated to tell that a Go prod build is >10x faster than a Rust dev build

So, I get your point for production build, that it needs some special optimization that maybe doesn't happen for Go, but I don't need any optimization when doing Dev testing and this could well remain totally unoptimized. Then I would at least expect for an "un-optimized" dev Rust build to be roughly as fast as a production Go build. At least not >10x slower

It could, if it stopped doing a lot of things it does which the Go compiler doesn’t.

Or of course if the Go compiler started doing them so it became a lot slower.

One example is “full”monomorphization of generics. But there are lots of such examples.

Usually though I find the Rust compilation speed a non issue, so long as “cargo check” and the IDE analysis is great, I just rarely compile to begin with.

The borrow checker is not an insignificant cost. Maybe you could imagine an incremental compilation mode that just didn't evaluate the borrow checker for faster development.

As other commenters have noted, the Go backend is extremely simplistic ("barely an optimizing compiler"). Rustc is also a lot faster in -O0 mode than any optimizing mode. But -O0 is somewhat dumber than Go's compiler. You could imagine an -O1 (or -O0.5) with compilation time vs performance tradeoff similar to Go, but it isn't there today. There's also an attempt to adopt a more simplistic backend (cranelift) into Rustc to improve codegen performance, but so far it hasn't provided much speedup.

Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.

As an end user of Rust, I think the borrow checker seems slow because it's one of the last phases to run during vscode's real-time feedback. More than once I've been in the midst of a long refactoring session, and finally fix what I think is the very last syntax problem. But then the borrow checker finally gets to run, and then I learn about a whole new set of problems.

Apologies, I was under the impression it was a significant cost. Do you have any good analysis of where Rust compiler time goes you could link to?

Here is a nice article that goes into detail: https://fasterthanli.me/articles/why-is-my-rust-build-so-slo...

Here is an older article that compares compilation times between multiple different libraries, where one of them does spend a significant (and majority of the) time borrow checking: https://wiki.alopex.li/WhereRustcSpendsItsTime

https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good overview. In general it varies depending on the crate but we track the performance at https://perf.rust-lang.org/ - if you look at cargo, for example, over 60% of the time is spent in codegen through LLVM: https://perf.rust-lang.org/detailed-query.html?commit=222d1f...

For someone who hasn’t written any larger rust programs. Is the compile time worse than c++?

Same order of magnitude, i.e. depends, but really bad if you actually use the language.

The quick-lint-js project ported a part of their code from C++ to Rust. Rust's compilation time scaled less well with the size of the code base. Here is a detailed report:

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Reply on news.ycombinator.com