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

31–40 of 217 posts

Re: Why is my Rust build so slow?

#31

Post by celeduc »

twblalock wrote: post #28

This much complexity and the tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign. It means the complexity of the problem space is not solved by the language, and the responsibility of solving it is being passed on to the users. You might react to this by saying that slow build times are not a big deal. That's a mistake -- iteration is key to productivity an…

Build times matter a lot. I've spent a lot of my career working to reduce build and test cycles to improve productivity. Rust is the one environment where no matter how much time we threw at the problem it never got better.

Re: Why is my Rust build so slow?

#32

Post by geewee »

twblalock wrote: post #28

This much complexity and the tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign. It means the complexity of the problem space is not solved by the language, and the responsibility of solving it is being passed on to the users. You might react to this by saying that slow build times are not a big deal. That's a mistake -- iteration is key to productivity an…

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.

https://pingcap.com/blog/rust-compilation-model-calamity#rus...

Re: Why is my Rust build so slow?

#33

Post by akavel »

CameronNemo wrote: post #8

This article is fairly strange. The author keeps changing settings to make the release profile more like a debug profile. Wouldn't I want LTO for releases? Also this is a really long article with a lot of cool tricks and interesting information. Like the author's binary crate, they might consider splitting this article apart. Or at least adding a TOC!

As I read it, the flag changes are to find the source of the slowdown. I.e. if disabling LTO for a moment would improve the compilation speed drastically, then I probably still want it enabled but may now want to see if there are ways to "please" the LTO, to massage the input to be somehow more LTO-friendly and allow it to work faster - or find some other ways to optimize LTO (like how they experiment with alternative linkers in other parts of the article). It helps to understand whether the biggest gains can be had from focusing on optimizing this particular area. Also it helps quickly and roughly establish what's the "best case" improvement they can probably achieve, as presumably the debug-build set of options is bent on compilation speed.

Still, in the end the biggest performance gain seems to have been found faaar away from LTO in this case.

Re: Why is my Rust build so slow?

#34

Post by saurik »

lpapez wrote: post #30
twblalock wrote: post #28

This much complexity and the tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign. It means the complexity of the problem space is not solved by the language, and the responsibility of solving it is being passed on to the users. You might react to this by saying that slow build times are not a big deal. That's a mistake -- iteration is key to productivity an…

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…

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 :/.

Re: Why is my Rust build so slow?

#35

Post by codeflo »

twblalock wrote: post #28

This much complexity and the tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign. It means the complexity of the problem space is not solved by the language, and the responsibility of solving it is being passed on to the users. You might react to this by saying that slow build times are not a big deal. That's a mistake -- iteration is key to productivity an…

I agree, and even as someone who holds Rust in high regard, I’m becoming increasingly frustrated by this. There doesn’t seem to be one clear root of this problem.

Some of it is the language not being designed with ease of compilation in mind, unlike let’s say, to pick an extreme example, Go. Some of it is the tooling and default settings, especially around incremental compilation, linkers etc. People are working on this, but it takes time.

But unfortunately, a lot of the problem is with the ecosystem, as hinted at in the article. There seems to be no limit to the amount of code bloat and compile time complexity that people are willing to accept to win some microbenchmarks. This includes some very popular crates with lots of dependents, like Tokio.

In the C++ world, the popular “boost” library has a similar problem, and I know shops that avoid it, or large parts of it, simply because the compile times would be unbearable. I really hope that parts of the Rust community start to make similar decisions.

Re: Why is my Rust build so slow?

#36

Post by saurik »

geewee wrote: post #32
twblalock wrote: post #28

This much complexity and the tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign. It means the complexity of the problem space is not solved by the language, and the responsibility of solving it is being passed on to the users. You might react to this by saying that slow build times are not a big deal. That's a mistake -- iteration is key to productivity an…

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 parallelism caused by the "crates" model combined with link time optimizations and incremental compiles being off by default. You don't need to make a fundamentally faster code generator that makes worse output to deal with this: the performance losses you get from parallel, incremental, and separate compilation techniques are so minimal that only the most serious C++ projects go out of their way to combine translation units and activate LTO.

Re: Why is my Rust build so slow?

#37

Post by JoshTriplett »

est31 wrote: post #29
JoshTriplett wrote: post #26

Earlier quoted context omitted.

I've been working on stabilizing some options like this, with exactly that approach: the functionality is stable but the exact details aren't. For instance, instrument-coverage will work like that, generating coverage data that requires the current version of LLVM coverage tools to work with. timings doesn't seem especially hard to stabilize; I'll take a look at it.

But you can't just say that the flag is stable while the output may change. Third party tools might rely on the output. This is okay for things read by humans (say the error messages) but fails for things that tools are parsing, like data needed for code coverage tools. Stabilization of instrument-coverage, as proposed, is a bad idea in my opinion. I'm sad that the concerns have not been addressed: https://github.com…

https://github.com/rust-lang/rust/pull/90132#issuecomment-95...

It depends on whether what you're stabilizing is an output format or a set of functionality. I think it's reasonable to do the latter.

(If you'd like to talk about that further, I would suggest Zulip.)

Re: Why is my Rust build so slow?

#38

Post by saurik »

CameronNemo wrote: post #8

This article is fairly strange. The author keeps changing settings to make the release profile more like a debug profile. Wouldn't I want LTO for releases? Also this is a really long article with a lot of cool tricks and interesting information. Like the author's binary crate, they might consider splitting this article apart. Or at least adding a TOC!

(Note: I am a long time systems software developer but I don't use Rust, so while this made perfect sense to me maybe it shouldn't have due to some Rust thing I don't know about.) I'm guessing the issue is how there is really a stage between "debug" and "release" where you need the code to run fast enough to be worth testing and using but you don't need to eek out then final 0.5% of performance by cranking all the settings. When working on such projects you only drop down to a "debug build" if you end up entirely screwed trying to figure out why something is broken because the optimizer has messed up the debugger, and you care OK with the lower performance as you've already isolated the issue.

Re: Why is my Rust build so slow?

#39

Post by yoru-sulfur »

CameronNemo wrote: post #8

This article is fairly strange. The author keeps changing settings to make the release profile more like a debug profile. Wouldn't I want LTO for releases? Also this is a really long article with a lot of cool tricks and interesting information. Like the author's binary crate, they might consider splitting this article apart. Or at least adding a TOC!

The long meandering nature is kind of the authors style. He typically picks a problem then goes deep into it exploring whatever tangents may crop up while doing so.

ToC sounds like a good idea though

Re: Why is my Rust build so slow?

#40

Post by codeflo »

saurik wrote: post #34
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…

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 matches my experience as well. It takes a nontrivial amount of discipline, but it’s possible to structure a C++ project for fast builds. In theory, having a module system that isn’t based on text substitution should give Rust an advantage, but on the minus side, the crate structure gives you fewer knobs to optimize.
Post reply on HN