Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is my Rust build so slow?

fasterthanli.me

Post reply on HN
Print view View original

171–180 of 217 posts

Re: Why is my Rust build so slow?

#171

Post by sanxiyn »

pornel wrote: post #138
sanxiyn wrote: post #16

Earlier quoted context omitted.

You are right. There is no technical reason it should be as slow as it is. It's just that not enough resource was spent to make it fast. I mean, if this were a higher priority, Rust issue #26600 would have been fixed years ago. https://github.com/rust-lang/rust/issues/26600

Looks like it's blocked by lack of required LLVM support.

Again, if this were a priority, it would have happened. But compile time is low priority. Its priority is lower than a quite niche feature like cross-language LTO, which happened in 2019.

https://blog.llvm.org/2019/09/closing-gap-cross-language-lto...

Re: Why is my Rust build so slow?

#172

Post by mamcx »

pyjarrett wrote: post #161
mamcx wrote: post #154

Earlier quoted context omitted.

ADA. This is a false(ish) dilema. The problem of Rust is that is made with a C++ mindset. Is VERY hard to make compiler fast if it follow what C/C++ do (Go is the only evidence against!). Is a death by thousands cut. The syntax is the FIRST and big one. How you chose it will impact all the pipeline. Then the rest...

Ada isn't entirely safe. It does avoid C-string issues using length-based strings, bounds-checking array access and other features like access types instead of pointers, but it is still possible to hold onto an access to dynamically allocated memory after deletion (though you can somewhat mitigate this with smart pointers).

Sure, neither Rust.

But the things that make Rust safe are not that much slower. Macros, Generics, all that syntax, all that lang complexity (ie: Not just the semantics but the way is surfaced) have a bigger impact.

Re: Why is my Rust build so slow?

#173

Post by Ar-Curunir »

menaerus wrote: post #50
lpapez wrote: post #30

Earlier quoted context omitted.

That is because the languages are different and choose different tradeoffs. The tradeoffs might make a language inapplicable in your domain. Rust has always been marketed as a "systems programming language". C++ is Rust's closes competitor in this domain space and it suffers from terribly slow compiling as well. I would say that due to headers, massive portability baggage and a lack of a standard build system, compil…

To be more precise, rust is a competitor to C++ and not the other way around. Also, compiling C++ is _not_ worse than compiling rust projects but again the other way around. Although compilation times are a hog in both of these languages, it is well known that this is actually one of the biggest rust pain points. In general, long compilation times are mostly attributed by the complexity of things (algorithms) that co…

The rust compiler doesn’t spend a lot of time doing things like type checking and borrow checking, except in pathological edge cases (like in the article), and these edge cases are quickly fixed (eg this one was a regression that’s already fixed).

Most time tends to be spent in LLVM. That will also go down over time as the quality of emitted LLVM IR improves due to optimizations in rustc itself.

Re: Why is my Rust build so slow?

#174

Post by yawaramin »

howinteresting wrote: post #170
yawaramin wrote: post #166

Earlier quoted context omitted.

Why doesn't Rust default to one crate per source file then? Wouldn't that make the build massively parallelized :-)

Because you can have circular dependencies within a compilation unit, but not between units.

That actually sounds more appealing to me. In fact it's exactly how OCaml works. Of course in OCaml compilation units are just files already.

Re: Why is my Rust build so slow?

#175

Post by Ar-Curunir »

saurik wrote: post #36
geewee wrote: post #32

Earlier quoted context omitted.

Often when building compilers you trade the speed of compilation against the speed of execution[1], and Rust has (traditionally) chosen the speed of executiong over making the compiler fast. This won't necessarily always be so, there's e.g. a new compiler backend called cranelift in the works, that makes compilations 30%ish faster, and in return the code isn't as optimized - which is good for a faster inner cycle. ht…

The biggest issue cited in this article is a regression in the type checker, which is an open bug that apparently is just lower priority than whatever else the Rust team is working on instead of ensuring compilation time is fast. Only once that was worked around did they article really start having to pay attention to the code generation and linking stages, and the issues there seem to mostly be about lack of paralle…

Contrary to what you say, rust compilation speed is a top priority for rustc developers. Rust compiler times have gone down YoY every year for the past few years. See, eg, https://nnethercote.github.io/2021/11/12/the-rust-compiler-h...

Re: Why is my Rust build so slow?

#176

Post by estebank »

varajelle wrote: post #120
dom96 wrote: post #116

Earlier quoted context omitted.

This is quite interesting. Is `syn` just an interface to the Rust compiler's Rust parser or is it a completely separate implementation of the parser that works at compile-time? Hopefully it's not the latter but then I wonder where the slowness comes from.

it's a completely separate implementation of the parser I wish that the proc_macro API from the compiler would do that instead.

syn also let's you define your own parsers for non-Rust syntax, way beyond what rustc could provide.

Re: Why is my Rust build so slow?

#177

Post by dwheeler »

estebank wrote: post #98
dwheeler wrote: post #94

Earlier quoted context omitted.

Compiler authors can often make compilation faster, but they have to work at it and think carefully through the problem. It has to be a focus not an afterthought. Years ago the GNAT Ada compiler authors intentionally avoided implementing precompiled headers. They instead focused on very fast lexical analysis (using a small handwritten lexer optimized for lower case letters because that was the usual case). By careful…

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 sou…

Excellent to hear! Don't get me wrong, I like Rust. I'm hoping we can get compilation speeds up over time, though, that is a common complaint.

Re: Why is my Rust build so slow?

#178

Post by estebank »

mamcx wrote: post #154
ModernMech wrote: post #124

Earlier quoted context omitted.

The third axis in compiler development is safety. The compiler writer’s dilemma can be framed as: fast execution, safe execution, fast compilation — choose 2.

ADA. This is a false(ish) dilema. The problem of Rust is that is made with a C++ mindset. Is VERY hard to make compiler fast if it follow what C/C++ do (Go is the only evidence against!). Is a death by thousands cut. The syntax is the FIRST and big one. How you chose it will impact all the pipeline. Then the rest...

Syntax parsing is nowhere close to the critical path for Rust, and I suspect there are no languages where it is today.

Re: Why is my Rust build so slow?

#179

Post by estebank »

swiftcoder wrote: post #147
Narretz wrote: post #111

Earlier quoted context omitted.

The two biggest time savings where accomplished by using a version without the regression bug, and using incremental builds in debug mode for local dev. Bugs can be introduced in any language, so the only gotcha to be fixed is that maybe incremental compile should be the default.

Note that incremental builds are the default for debug builds. For reasons that are not entirely elaborated in the article, the author is using release builds for local development.

In some verticals the only way to properly exercise and test the resulting binary is in release mode. Think things like DBs, game engines, etc. It's why good debug information in release is needed.

Re: Why is my Rust build so slow?

#180

Post by estebank »

yawaramin wrote: post #164
fasterthanlime wrote: post #113

Earlier quoted context omitted.

Seems like you really need to finish reading the article: hot builds take 3s by the time I find the regression that caused pathological compile times.

You mean, by the time you split up the project into a bunch of tiny crates and mention: > I don't love how the dependency graph looks After adding this complexity to the project, yes, some of the crates are building in ~3s, if they are the only ones that needed to be rebuilt. Meanwhile, in a Java project there is none of this artificial crate splitting. Sure, Java projects have other nonsense, but they don't force yo…

It's a tradeoff: if you make the file the language's compilation unit, then you can't have "circular imports" to allow end users divide their code in an ergonomic manner with fewer "arbitrary" restrictions. We can argue all year on whether Rust settled on the right side of that trade-off.
Post reply on HN