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

61–70 of 217 posts

Re: Why is my Rust build so slow?

#61

Post by estebank »

Uther wrote: post #58
izacus wrote: post #46

Earlier quoted context omitted.

Rust seems to have inherited two favorite C++ development process features: long compilation times and incomprehensible error messages that aren't really related to the actual issue (e.g. just how C++ barfed out a bunch of template errors, borrow checker really loves to barf out very obscure error messages when there's an issue with lifetimes).

While compilation time is a well known Rust pain point, Rust error messages are really one of the best part of the language. Complicated error messages are clearly no a common occurrence unless you rely heavily on meta-programming tricks, and that is not common in Rust, unlike C++.

And the intention is to improve those too. It's hard, and I would prefer crate writers show more restrain than they do, but we have to meet users where they are.

Re: Why is my Rust build so slow?

#62

Post by brabel »

Ygg2 wrote: post #49
izacus wrote: post #46

Earlier quoted context omitted.

Rust seems to have inherited two favorite C++ development process features: long compilation times and incomprehensible error messages that aren't really related to the actual issue (e.g. just how C++ barfed out a bunch of template errors, borrow checker really loves to barf out very obscure error messages when there's an issue with lifetimes).

What the hell are you on about? Saying in it inherited them, just proves you probably didn't use either. While compilation times are longer than say Go, they definitely never felt too long, compared to say Java. But your comment around errors takes the cake. Like maybe, if you use some combination of macros expansion and traits it could get confused. But Rust errors are on par with Elm. They show the line, they show…

> they definitely never felt too long, compared to say Java.

Woah... now I am the one who have to ask: what the hell are you on about??

I work on Rust and Java projects, if you exclude running tests, Java compiles very very fast compared to pretty much any language... Rust is a lot slower to compile even on the much smaller projects I've worked on... in this post, a very small project (I think it's like 16,000 LoC, it's mentioned in the beginning) was taking over a minute even on hot builds... To get a build to take this long in Java you would need to have several million LoC! Even if you don't use something like Gradle to cache compilation units and just compile everything from scratch with javac.

Re: Why is my Rust build so slow?

#63

Post by spockz »

est31 wrote: post #24
howdydoo wrote: post #12

I've always wondered why useful flags like `-Z timings` are not available on stable. I guess they're worried about the output changing in a future stable release, but I don't think anyone would expect the reports to look exactly the same and list exactly the same compilation phases, etc, for all eternity. I think that for diagnostic features, people would be just fine with a loose stability guarantee that allows the…

> I think that for diagnostic features, people would be just fine with a loose stability guarantee The issue with this is that the output might be parsed by downstream tools that assume a special format. They might break by a change in the output.

It sounds like these tools should be using some machine format. Perhaps json or something as opposed to human readable strings. Then again, also the layout of the json might change but at least that can potentially be done in a backwards compatible manner.

Re: Why is my Rust build so slow?

#64

Post by lordnacho »

menaerus wrote: post #55

Whenever I read articles like this one, it leaves me wondering in what parallel reality do I live in. Or I could put it differently and say that authors making blogposts complaining about full rebuild cycle taking staggering 2 minutes live in a pink bubble. Everyday reality in somewhat complex industry-placed product is 10x that if you're lucky. More often than not it's few hours before you're able to build the whole…

Same here, I don't get what the complaint is. A friend at a major bank says they used to take 7 hours to build their C++ trading system before someone cleaned it up.

2m to build a release and a few seconds to build incremental seems fine to me. Most of the time when I'm coding I just want the compiler to tell me if the syntax is wrong, and it is pretty snappy with rust.

Re: Why is my Rust build so slow?

#65

Post by brabel »

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…

That's a pretty bad incentive though and you end up with very large dependency trees similar to JS. And we know how that went.

OTOH there might be a benefit too as more code becomes re-usable in independent crates.

Re: Why is my Rust build so slow?

#67

Post by brabel »

_ma_rit_231 wrote: post #18

The long compile times are actually one of Rust's problems I could live with. Having to depend on so many third party libs is a much bigger issue for long term maintainability and security. Also the time choosing the libs is not neglectible. At work we currently developing a mid size project (CLI and HTTP API) with Go and the standard lib is simply amazing.

Long compile times and having lots of small crates in your dependency tree, surprisingly, are related in that, as the author mentions in the article, splitting libraries into separate crates makes the compilation of each individual crate much faster because crates you depend on are compiled in parallel, and don't ever need to be re-compiled after the first compilation (so hot builds become much faster) while the current crate being compiled becomes naturally much smaller, hence faster to compile, when you pull chunks of it into other crates.

Re: Why is my Rust build so slow?

#68

Post by dmitriid »

brabel wrote: post #62
Ygg2 wrote: post #49

Earlier quoted context omitted.

What the hell are you on about? Saying in it inherited them, just proves you probably didn't use either. While compilation times are longer than say Go, they definitely never felt too long, compared to say Java. But your comment around errors takes the cake. Like maybe, if you use some combination of macros expansion and traits it could get confused. But Rust errors are on par with Elm. They show the line, they show…

> they definitely never felt too long, compared to say Java. Woah... now I am the one who have to ask: what the hell are you on about?? I work on Rust and Java projects, if you exclude running tests, Java compiles very very fast compared to pretty much any language... Rust is a lot slower to compile even on the much smaller projects I've worked on... in this post, a very small project (I think it's like 16,000 LoC, i…

> Java compiles very very fast compared to pretty much any language

In my experience C# compiles faster, but I still agree with you on all points.

Re: Why is my Rust build so slow?

#69

Post by menaerus »

jokethrowaway wrote: post #60
menaerus wrote: post #50

Earlier quoted context omitted.

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…

I disagree that it's a pain point in C++ or in Rust. You're generally just doing a lot more stuff and shifting the pain to incremental debug builds (so that the slow path doesn't need recompilation) is a perfectly viable solution. Template metaprogramming has never been the pain point in C++ for me because nobody wanted to use templates (after a certain points), huge deps are. Anecdotally, the slow builds I've experi…

I live and breathe C++ full time for more than a decade now. Compiling C++ _has_ always been pain point and big efficiency killer. Especially if you come from other languages (I don't but I enjoy learning other stuff too). It doesn't matter if you're directly writing your own template code or not because you're always gonna pull it in indirectly, even in most simplistic and inrealistic case when your sole dependency is C++ runtime library.

OTOH debugging C++ build times is no more than recompiling your code with -ftime-trace and inspecting it with ninjatracing, which btw is a great tool.

However, getting the data as you see is not the real challenge here but in how to use this data to optimize your build pipeline while keeping the functionality and not introducing more technical burden. That is very difficult and for many projects questionable if the benefits will outweigh the total cost invested in it.

Re: Why is my Rust build so slow?

#70

Post by bullen »

Ok, I didn't read all that but that is 100W of power.

My solution to be able to work on a 5W Raspberry 4 is to use C (arrays for cache misses), compile with GCC to a .so and hot-deploy that into my engine.

That way I have a zero dependencies engine (only stb_ttf and kuba_zip) that compiles from scratch in 30 seconds and the game .so takes ~1 second.

I don't even have to use a build system or many cores to compile.

Simple and low power.

Downvotes without commenting, proves my point.

Post reply on HN