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

101–110 of 217 posts

Re: Why is my Rust build so slow?

#101

Post by formerly_proven »

aliceryhl wrote: post #77
codeflo wrote: post #35

Earlier quoted context omitted.

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 t…

Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to find any big wins yet, but one thing has been pretty clear from the benchmarks: The number of dependencies of Tokio is not the problem. They all compile pretty fast and can all compile in parallel. Tokio itself takes a lot longer than the dependencies. (Excep…

So I've read "syn" and "slow rust compiles" in pretty much every discussion of "slow rust compiles" and finally googled it and... syn is a Rust parser? For use in macros? Because procedural macros operate on tokens and not an AST? Hm. I'm sure there are reasons for how it ended up like this, but it does smell kinda funny.

Re: Why is my Rust build so slow?

#102

Post by jeffparsons »

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'm very happy with my overall experience using Rust, but I would never say "slow build times are not a big deal". I can work around them just fine by myself because it's the kind of thing I'm used to doing, but as more of my team (especially more junior members) start using it for projects, the slowness becomes a big deal. And I don't see that as a problem with my team at all — it's very much a problem with Rust. Especially if you're doing the kind of work where you're switching fairly quickly between different projects (bug blitz, cross-cutting platform work, etc.), you simply can't afford to be wasting time trying to work around bad-by-default compiler performance.

That said, I don't think that the level of slowness we're talking about here is actually an intrinsic property of Rust. Specifically, I think there are a handful of strategies that would really improve things:

- For teams, dead-simple out-of-the-box sccache integration, and officially supported Terraform (etc.) projects for setting it up in your corporate cloud environment. Then your "cold" builds for a project you've never touched before could be a lot quicker.

- A set of inbuilt use-case-driven named profiles for Cargo beyond just "debug" and "release", which you could set as the default for your "debug" or "release" builds. I'm thinking things like "prioritise-runtime-performance-and-incremental-build-time" (maybe with a better name) that sets the right kinds of flags to make that work, given that all those things are achievable if you tweak flags manually.

- Using a faster linker by default, e.g. Mold. Although I don't know whether there are portability or other issues here. Maybe it could just be used where possible?

- Binary repositories. I think people are too quick to dismiss these on the grounds that different features enabled on a crate makes it produce a very different output. You could cache the three most common configurations or something.

TL;DR: I think just not a lot of time has gone into tackling this at a high level, because there have been other priorities, and there are whole lot of directions that could be explored that might make a big difference.

Re: Why is my Rust build so slow?

#103

Post by gameswithgo »

vladvasiliu wrote: post #72
codeflo wrote: post #35

Earlier quoted context omitted.

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 t…

> 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. But isn't this the right trade off for something like Tokio which is at the base of applications which e…

Yes, a slow compiletime of a dependency is less painful since you don’t do full recompiles that often, but things can spiral out of control if you have say 50 dependencies and many of them are real slow and you are on your old dual core laptop and find it takes hours, and so on.

Re: Why is my Rust build so slow?

#104

Post by UtherII »

timvisee wrote: post #99
xpressvideoz wrote: post #87

Earlier quoted context omitted.

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.

The java slow build time is usually a dependency problem too. On similar complexity, Java is usually as fast or even faster than Rust.

Re: Why is my Rust build so slow?

#105

Post by hu3 »

forrestthewoods wrote: post #82
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…

> 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. What languages do it best? JavaScript is a dystopia of stacked bundlers. Python dependencies and deployment is a toxic superfund wasteland. You’re not wrong that it’s a problem. But as far as I can tell build+deployment is an unsolved problem for non-hobby projects in mos…

Go is known for having really fast compilations.

Almost Pascal levels of fast.

Re: Why is my Rust build so slow?

#106

Post by flohofwoe »

Very interesting and detailed article how to profile the Rust toolchain, but TBH, after the reveal that the project uses several hundred dependencies my first thought was: "well, there's your problem". One thing or another will always be broken in such a complex scenario.

Re: Why is my Rust build so slow?

#107

Post by snorkel »

aliceryhl wrote: post #77
codeflo wrote: post #35

Earlier quoted context omitted.

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 t…

Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to find any big wins yet, but one thing has been pretty clear from the benchmarks: The number of dependencies of Tokio is not the problem. They all compile pretty fast and can all compile in parallel. Tokio itself takes a lot longer than the dependencies. (Excep…

First of all, Tokio is my favorite async framework, so thank you and the Tokio team! And second, I appreciate that cargo/rustc compiler errors are clear, helpful, and guide me toward cleaner and thread-safe coding where most other languages happily let me create unsafe hidden race bugs all day long with no warning … oh but they compile so much faster! (I don’t care) The slower compile time really doesn’t bother me when I’m getting a more stable end result… but I’m glad the maintainers are working on improving compile time anyway.

To me the extra compile time makes sense when rust is showing me many unsafe coding issues that languages seem to ignore even with their strict warnings enabled.

… and I don’t get all of the complaining about rust. I’ve written code in a lot of languages and rust has its quirks too, as they all do, but I really like it!

Re: Why is my Rust build so slow?

#110

Post by jhgg »

formerly_proven wrote: post #101
aliceryhl wrote: post #77

Earlier quoted context omitted.

Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to find any big wins yet, but one thing has been pretty clear from the benchmarks: The number of dependencies of Tokio is not the problem. They all compile pretty fast and can all compile in parallel. Tokio itself takes a lot longer than the dependencies. (Excep…

So I've read "syn" and "slow rust compiles" in pretty much every discussion of "slow rust compiles" and finally googled it and... syn is a Rust parser? For use in macros? Because procedural macros operate on tokens and not an AST? Hm. I'm sure there are reasons for how it ended up like this, but it does smell kinda funny.

It allows for things like https://docs.rs/typed-html/latest/typed_html/ to exist.
Post reply on HN