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

21–30 of 217 posts

Re: Why is my Rust build so slow?

#21

Post by charcircuit »

the8472 wrote: post #19
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?

> 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 able to quickly iterate on stuff I work on.

>Does it actually only change a single byte in the binary?

It would be possible. I could do it myself using binary ninja / ghidra. I just want to be able to iterate quickly and try out multiple different values. I understand it's not that simple of a problem, but I just want it to work else I'll gravitate to making projects in some other language.

Re: Why is my Rust build so slow?

#22

Post by PragmaticPulp »

I had a hunch that Warp would be the answer when I started reading.

I hit the same issue and worked around it the same way (boxing). My build times also went from 1-2 minutes down to a couple seconds.

Generally speaking, most of my Rust work has been reasonably fast on modern hardware. Waiting 3-5 seconds for incremental builds isn't a big deal. I've only seen the excessive compile times with cold starts or in weird edge cases like the Warp issue.

Re: Why is my Rust build so slow?

#23

Post by bogeholm »

charcircuit wrote: post #21
the8472 wrote: 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…

> I just want it to work else I'll gravitate to making projects in some other language

Sounds like Go or C++, or maybe evne Zig, are good choices for you then

Re: Why is my Rust build so slow?

#24

Post by est31 »

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.

Re: Why is my Rust build so slow?

#25

Post by larsrc »

charcircuit wrote: post #9
sjakwjsjsisj wrote: post #6

Earlier quoted context omitted.

Use bazel? Individual files won't be faster but it's been a wonder for whole project compilations

This could be interesting to look into. It looks like there already exists a project that can generate BUILD files for external crates. My 2 main gripes with Bazel was that it was a pain having to rewrite the build system for all of my dependencies and that it's claim of being reproducible is weak in the sense that there are not even warnings when you use resources from the base system (eg. compilers can include file…

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.

Re: Why is my Rust build so slow?

#26

Post by JoshTriplett »

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

Re: Why is my Rust build so slow?

#27

Post by charcircuit »

larsrc wrote: post #25
charcircuit wrote: post #9

Earlier quoted context omitted.

This could be interesting to look into. It looks like there already exists a project that can generate BUILD files for external crates. My 2 main gripes with Bazel was that it was a pain having to rewrite the build system for all of my dependencies and that it's claim of being reproducible is weak in the sense that there are not even warnings when you use resources from the base system (eg. compilers can include file…

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.

Re: Why is my Rust build so slow?

#28

Post by twblalock »

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 and other languages do it better.

Re: Why is my Rust build so slow?

#29

Post by est31 »

JoshTriplett wrote: post #26
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'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/rust-lang/rust/pull/90132#issuecomment-94...

Re: Why is my Rust build so slow?

#30

Post by lpapez »

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, compiling C++ is even worse. And that is a language that has been around for 30+ years.

I agree that build times are important (i.e. PR build takes us 30 minutes which is insane), but sometimes you don't really have a choice. When you do have a choice, then by all means reap the benefits of fast compilation that languages such as Go or C can offer.

Post reply on HN