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

91–100 of 217 posts

Re: Why is my Rust build so slow?

#91

Post by lordnacho »

estebank wrote: post #88
alexchamberlain wrote: post #84

Earlier quoted context omitted.

Warp uses a lot of generics, which can produce extremely deep and long types. In turn, these cause a particular compile stage to take a long time (> 40 seconds). Boxing disguises/splits the chain by taking a pointer to a trait object, which doesn't require the same depth of checks. (This is especially important if the algorithm is superlinear, which is implied but not stated in the article.)

The problem is not the length of the types, but rather the number of "obligations" introduced by each type. If you have Foo >, and each one of those types has a single trait bound, the resulting type now has >3 obligations to evaluate (> because you also have Sized and WF checks for them as well). The deeper the type depth, the more potential obligations you end up with, which have in some cases can have exponential…

Still not sure I get it. If I box a generic, why does the time to evaluate the bounds change?

Re: Why is my Rust build so slow?

#92

Post by Ygg2 »

xpressvideoz wrote: post #87
holoduke wrote: post #83

I came from java and compared to that even our slowest rust build time is faster than I have ever experienced in java. I remember we had a Java springboot application who had a buildtime of 8 minutes on my 2015 MacBook. I am so happy I don't have to deal with this anymore.

That's more to do with Spring, not Java. The compilation time of Java is infinitely faster than that of Rust.

Well, in this case. It had to do with Warp hitting a regression in compiler.

Spring is one of most if not THE ubiquitous piece of Java software. All Java shop I worked for, had Spring

Comparing Spring+Java to Rust+Warp is imo fair game.

Re: Why is my Rust build so slow?

#93

Post by [deleted] »

mtzet wrote: post #89
saurik wrote: post #34

Earlier quoted context omitted.

C++ projects tend to support massively parallel builds, despite what people tend to complain about with header files. The issue here in this article was partly that Rust only compiles crates in parallel, but while people tend to have lots and lots of C++ translation units, they don't have lots and lots of Rust crates. Languages seem to be moving in the wrong direction here :/.

That's a bit misleading though. The problem with header files is that they tend to get (textually) included in lots of compilation units, and hence rebuilt a lot of times. I did an experiment on a codebase at work where turning on unity builds -- so effectively everything is a single c++ file -- resulted in a 2x speedup in real time, and a 12x reduction in 'user' time. Of course, such approaches lead to slower hot re…

[deleted]

Re: Why is my Rust build so slow?

#94

Post by dwheeler »

menaerus wrote: post #90
LowLevelMahn wrote: post #71

Earlier quoted context omitted.

In general, long compilation times are mostly attributed by the complexity of things (algorithms) that compilers are trying to do for you in order to produce machine code and not because there's a lack of standardized build system (a bad idea) nor because of existence of headers. that is not true - most of the project i worked for suffered from header parsing a lot - sometimes more then 50%, in 100k-1MioK lines of co…

I tend to disagree with this. I've optimized build times on number of occasions on different projects, each being in the venue of multi-million LoC, and none of them benefited greatly from employing precompiled headers, which essentially should help alleviate exact this gap. Running the build with -ftime-trace almost always has shown in my experiments that the bottlenecks are either in exploding number of template in…

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 optimization of a small part of the compiler they made the recompilation of headers faster than loading a precompiled header!! More info: https://dwheeler.com/essays/make-it-simple-dewar.html

Maybe the Rust team needs to add timers to their test suite. This kind of big regression in compilation time should have been caught by the test suite.

Re: Why is my Rust build so slow?

#95

Post by estebank »

lordnacho wrote: post #91
estebank wrote: post #88

Earlier quoted context omitted.

The problem is not the length of the types, but rather the number of "obligations" introduced by each type. If you have Foo >, and each one of those types has a single trait bound, the resulting type now has >3 obligations to evaluate (> because you also have Sized and WF checks for them as well). The deeper the type depth, the more potential obligations you end up with, which have in some cases can have exponential…

Still not sure I get it. If I box a generic, why does the time to evaluate the bounds change?

If you have T and box it, a new type Box is created. The compiler not only has to do typeck to make sure that you're using Box in both sides of an assignment, it also has to evaluate the bound on Box (in this case it's only that it is Well-Formed, an internal concept, because Box accepts unsized types, struct Box), but also evaluate all the bounds on T. If T: Foo, and the type you used for T is Bar, then by the time rustc actually has to confirm the type Box> is correct, it has to check that Bar: Foo and X: Qux, but you never wrote those close to the Box, these flow from other definitions. Multiply for every type with an explicit or implicit where clause (T: Foo, where ::C: D, associated types, etc.).

Re: Why is my Rust build so slow?

#96

Post by dragonelite »

xpressvideoz wrote: post #87
holoduke wrote: post #83

I came from java and compared to that even our slowest rust build time is faster than I have ever experienced in java. I remember we had a Java springboot application who had a buildtime of 8 minutes on my 2015 MacBook. I am so happy I don't have to deal with this anymore.

That's more to do with Spring, not Java. The compilation time of Java is infinitely faster than that of Rust.

For pretty 90 plus % of jobs you're pretty much confined to the Spring ecosystem. Same with C# and asp.net separating the two would be really weird.

Re: Why is my Rust build so slow?

#97

Post by dragonelite »

howdydoo wrote: post #11
charcircuit wrote: post #3

Rust's slow compiles are such a turn off for me. Like why does it take tens of seconds to recompile when I am just changing a single number in a file? Does it really need to waste so much of my time to change a single byte in the output binary?

I once had a similar project to OP that took 30 seconds to compile a one-line change (albeit on a 10-year-old CPU). I split it into about 7 crates, and got compiles down to 3 seconds. Since then I'm always vigilant about keeping crates nice and small. I think as long as you're keeping an eye on your crate sizes, compile times won't get away from you. This is different from C++ where each individual source file can be…

Sounds like the community still has to decide/write about what are best practises to make the compiler go fast?

Re: Why is my Rust build so slow?

#98

Post by estebank »

dwheeler wrote: post #94
menaerus wrote: post #90

Earlier quoted context omitted.

I tend to disagree with this. I've optimized build times on number of occasions on different projects, each being in the venue of multi-million LoC, and none of them benefited greatly from employing precompiled headers, which essentially should help alleviate exact this gap. Running the build with -ftime-trace almost always has shown in my experiments that the bottlenecks are either in exploding number of template in…

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 source of rust compilation slowness usually boil down to excercising a part of the language that has O(n²) behaviour, like match arm evaluation, trait bound evaluation, or huge expansion due to monomorphization or macro expansion, and the resulting huge linking times from that, or the bottleneck that proc-macros introduce (they get compiled before they can get executed, only relevant on fresh compiles).

The regression was (partly) fixed by adding caching: https://github.com/rust-lang/rust/pull/90423/files and if I recall correctly was introduced by a feature change that fixed a bunch of incorrectly rejected deeply nested trait bounds.

Re: Why is my Rust build so slow?

#99

Post by timvisee »

xpressvideoz wrote: post #87
holoduke wrote: post #83

I came from java and compared to that even our slowest rust build time is faster than I have ever experienced in java. I remember we had a Java springboot application who had a buildtime of 8 minutes on my 2015 MacBook. I am so happy I don't have to deal with this anymore.

That's more to do with Spring, not Java. The compilation time of Java is infinitely faster than that of Rust.

Unless you pull in a humongous amount of dependencies, Rust's compilation is still very very fast.

The dependency problem is a whole different issue. Hard to tackle, but it's one that must be solved.

Post reply on HN