Hacker News Reader

Comment by pizza234 | Hacker News Reader

This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language.

There are a few interesting reasons why Rust compilation time is slow and Go's is fast. Here's a summary of the first: https://pingcap.com/blog/reasons-rust-compiles-slowly.

In theory, with enough time and resources, Rust could see an efficient compiler, but this is something that can't be predicted, as it depends on its future success, or, to be clear, the backing it will have.

In practice, the Rust Cranelift backend could provide enough speed (for debug builds) that compilation times won't be slow anymore.

Something to consider is also that compilation is a tradeoff between compiling speed and runtime speed (Golang's favoring compiling speed), so one can't have both ends of the the spectrum at the same time.

View on HN

> and in particular, that they are entirely inherent to the language.

But... this is true. The design of the language is biased to make slow compiling across the full pipeline.

Is possible to get into a shout contest about this :), so just look at what Pascal(Delphi) do and how absurdly fast it is, despite the fact is still a "batch compiler".

So in the presence of pascal (that is even more complex than Go, to be a really close to C/C++ in capabilities) is clear that Rust is MADE to be slow.

And to the point, I used more than +12 languages already, super popular things like this:

https://endler.dev/2020/rust-compile-times/

NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.

I think the most accurate way to say it is that, while Rust compile times are not inherently slow, Rust has in most cases where where a desirable feature was at odds with compile times decided to sacrifice it. So while it is not inherently slow to compile, it was not designed to be easy to compile quickly either.

Delphi compile times are very slow on a reasonable 10 man year project. It doesn’t help the the IDE (and compiler?) was still 32 bit last year (even though it can compile 64 bit apps). Apart from some other toxic problems!

This toy project https://github.com/pjmlp/gwc-rs takes 16 minutes to compile from scratch on a core 2 machine, with 8GB and a SSD.

The original one in Gtkmm, takes around 5 minutes in release mode, if that much.

Hmm that looks slow. Can rust support binary patching like zig or is it impossible with the current design?

The biggest issue is lack of support for binary crates in cargo, so instead of pkg-config, you need to build the whole world when starting a new project.

So imagine being on the waiting lobby of an airport, reading about a cool Rust project and then trying to check it on your laptop. With luck it is finished compiling before being called for boarding.

Parent poster is referring to a full build, which are not really representative of a daily workflow. Incremental builds, in particular of a project where the large part of a full build is on external crates (which don't need to be recompiled) are much faster.

I can't test on an old machine, but modifying the project code and performing an incremental (standard) build, takes around 5 seconds on a modern machine.

> Parent poster is referring to a full build,

Yes

> which are not really representative of a daily workflow.

Only on Rust :). This is a "hack" that must be done to make Rust viable. In Delphi, a full compile is so fast that it's pointless to make it incremental.

Pro tip: use incremental compilation rather than full builds, especially if you're at an airport.

Pro tip: it only works if the crates are already compiled.

Another pro tip, switch to llvm linker.

Here is the thing with pro tips, maybe just maybe, I am an avid reader of Nicholas blog posts and know them all already.

I've profiled the compilation of a small but not trivially written crate (~5k lines, with macros, many UTs etc.), and the vast majority of the time (78%+) was actually spent on the LLVM side (see numbers in a post above).

In other words the Rust language design (as opposed to the compiler implementation) was not the bottleneck in the compilation time; the factors were well-known issues of the Rust compiler implementation: 1. it relies on LLVM, which is slow 2. it generates slow to compile IR code.

This is correct, and part of "the design of Rust make it slow". The use of LLVM is part of the design, and how use it is too.

Is like the people on the C-like languages (with the exception of Go) can't resits the temptation of make languages slow to use (yet, spend absurd amount of time on produce good binaries).

Is not that I not grateful of how good Rust/LLVM compiled binaries perform, in fact, is one of the big reasons I use Rust! but is kind of weird(?)/funny(?) that the languages itself are so slow.

I think is cultural. People on that side of the fence are so used to use sub-optimal tooling that don't mind too much to use another tool on the same feels. And if it provide "10%" increase on performance, get so happy, because is against the old, not agains the best.

> The use of LLVM is part of the design, and how use it is too.

This is false. There is the Rust Cranelift backend in development, which is actually usable already (depending on the project). Having a fast compiler for debug builds and a slow one for release ones is a setup that I can imagine being the future of Rust.

I've just built a project of mine and it took exactly half of the time to compile, when compared to the standard compiler.

It's actually crazy that they're even developing a JIT (although it requires dynamic libraries as dependencies, so its usage is and possibly will be limited).

> This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language.

Either that, or: it asks exactly that question rather than assumes that slow compilation is intrinsic to memory safety etc. But yes, there might be an implicit premise about some part of the Rust design contributing to slow compilation times.

Well, I've just profiled the incremental compilation of a 4.8k lines Rust project (using the `self-profile` option); top three offenders:

- LLVM_module_codegen_emit_obj: 47% of the time - LLVM_passes: 16% - codegen_module: 15%

Sample of Rust-specific passes:

- MIR_borrow_checking: 0.2% - resolve_lifetimes: 0.0%

The two passes above are arbitrarily picked, but anything other than the top three takes cumulatively 22% of the time.

Based on this, the Rust IR generation and LLVM are the bottleneck. I'd be interested in the opinion of somebody knowledgeable, since there may be non-obvious mistakes in the above reasoning.

This is a pretty common shape of the measurement, yes.

Hello Steve, I hope you're well and baking more breads for Christmas!

Thanks! I am working on two loaves right now, haha!

I'm not inappropriately assuming that design is fixed. I just wanted to know if it's possible. I'm not complaining about rust cause I don't know much than the basics also I have not worked with statically compiled languages.

Reply on news.ycombinator.com