5 ms·

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 a

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.

mamcx 6y ago
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.
- pizza234 6y ago
  > 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).

mamcx 6y ago

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.

pizza234 6y ago
> 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).