Live data from Hacker News

Why is my Rust build so slow?

fasterthanli.me

41–50 of 217 posts

Re: Why is my Rust build so slow?

#41

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…

Can this be automated? Could a script divide code into small crates upon compilation?

Re: Why is my Rust build so slow?

#42
post #19

Earlier quoted context omitted.

> Like why does it take tens of seconds to recompile when I am just changing a single number in a file? Impossible to tell without knowing more. Steps to reproduce the issue would help. Just consider how TFA went through many different things to investigate. > Does it really need to waste so much of my time to change a single byte in the output binary? Does it actually only change a single byte in the binary? Changin…

>Impossible to tell without knowing more. It was a rhetorical question based off my experience with rust. I was running into this issue with building a site using warp along with some other dependencies. Those projects have been deleted off my system. I am not interested in chasing down performance issues with the compiler. Remaking the site using C++ did not have me run into slow compile times. I just want to be abl…

Mhh, perhaps there is a place for detecting something like an "incremental change that ONLY changed static values".

It is indeed very frustrating trying to play with these kind of "settings" values.

Re: Why is my Rust build so slow?

#43
post #40
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 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.

Care to elaborate further on how to best structure a C++ project for fast builds?

Re: Why is my Rust build so slow?

#44
post #25

Earlier quoted context omitted.

Are you enabling sandboxing? Use `--spawn_strategy=sandboxed`, or better yet `--spawn_strategy=worker,sandboxed --worker_sandboxing`. That should disallow using files from the base system. This does disable multiplex workers,.which can make it more memory intensive. Working on that.

Yes, I was using their sandbox. They intentionally make their sandbox weak so you can use things like gcc from the system without having to bootstrap them. I don't know exactly what I tried since this was maybe a year and a half ago. I tried asking on their slack, but I think I was told that it was not possible. I don't have the project around anymore to try out your suggestion.

This is controlled by their default toolchain that includes /usr/include and such. You can define your own toolchain with different include directories.

Re: Why is my Rust build so slow?

#45
post #32

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…

I'm not disagreeing, but I could cold compile a million lines of Delphi code in a few minutes on a crappy laptop more than a decade ago. Delphi managed to be both fast to compile and a fast language; of course, it's not as sophisticated or complex a language as C++ or Rust. But still...

Re: Why is my Rust build so slow?

#46

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…

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).

Re: Why is my Rust build so slow?

#47
post #46

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…

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).

If you encounter incomprehensible error messages, I would encourage you to file a ticket at http://github.com/rust-lang/rust/issues. We consider them bugs and are diligent about dealing with them.

Re: Why is my Rust build so slow?

#48

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.

The difference between unmaintained code in a stdlib and unmaintained code in a third party lib is artificial.

I want the stdlib to be as lean as possible.

Also, as you just read, crates are compilation modules, hence generally this means more crates, lead to faster compile times.

Re: Why is my Rust build so slow?

#49
post #46

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…

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 what went wrong and how to fix. This is a far cry from C++, where using even a bit of templates, results in unintelligible mess.

Re: Why is my Rust build so slow?

#50
post #30

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…

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

In particular, biggest "offender" in C++ compilation model is almost always due to the usage of template metaprogramming whereas in rust I'd envision it's the compile time guarantees that must be offered through mechanisms such as borrow checker and alike.

Post reply on HN