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

191–200 of 217 posts

Re: Why is my Rust build so slow?

#191

Post by [deleted] »

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…

[deleted]

Re: Why is my Rust build so slow?

#192

Post by howinteresting »

yawaramin wrote: post #188
howinteresting wrote: post #187

Earlier quoted context omitted.

I don't think there is a moral justification for circular dependency scopes to always be individual files, especially given that import statements count as circular. The same issue in other languages where circular scopes are individual files leads to some horrible workarounds: * Python TYPE_CHECKING https://adamj.eu/tech/2021/05/13/python-type-hints-how-to-fi... * C/C++ header files But regardless, there is too much…

A 'moral' justification is not needed. We are talking about potentially massive build speed improvement here. Sounds like it could just be a build setting.

It would definitely be interesting to run some experiments with automatically splitting up Rust crates into compilation units if possible.

Re: Why is my Rust build so slow?

#193

Post by mplanchard »

pdimitar wrote: post #184
mplanchard wrote: post #132

Earlier quoted context omitted.

I work on a large rust project professionally, and we have tried to make build times a priority for CI. I’m just noting a couple of things that helped us a lot, in case they’re useful. - sccache is pretty much essential - beefiness: GitLab’s default runners for example are way too underpowered and made our builds take like 30 minutes (as opposed to 5 on a beefy machine in CircleCI). We’re working on switching to self…

> caching the cargo home can help. It wasn’t a massive gain relative to sccache, though. Similar story with caching the target directory Can you please clarify this point? Caching how?

Persisting it across jobs, using whatever your CI framework lets you do. We cache this stuff using the workspace cargo.lock checksum as the primary cache key

Re: Why is my Rust build so slow?

#194

Post by xbar »

lordnacho wrote: post #64
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.

I do not think that's the point.

Let's say you had a build that took 7 hours but if you took all the steps the author did, you would be able to build it in 30 minutes locally for debugging. Would that be interesting? That's about the amount of relative improvement the author saw.

Size of input varies, finding solutions to unnecessarily long compiles in rust are useful across many of them.

Re: Why is my Rust build so slow?

#195

Post by pdimitar »

yawaramin wrote: post #189
pdimitar wrote: post #186

Earlier quoted context omitted.

All that remains is for it to gain a build tool like mix or cargo. Futzing around with esy works but takes more time than I'm willing to regularly invest in it. Super excited about 5.00 and multicore!

I really go and forth on this. By separating the package manager and build tool, they leave the door open for either to be swapped out (which is what esy does, incidentally). The flexibility comes at a price of complexity, but it usually works well after climbing the learning curve.

I don't disagree and you're correct, the problem is that I'm usually investing 1-2h segments in playing with OCaml once every few weeks. Having 80% of that time swallowed by a build tool leaves a sour taste. :|

I get what you're saying but it applies to people who already work full time with OCaml. For guys like myself who want to periodically dip their toes and make a slow and steady progress... it makes us feel we're not welcome. (Obviously we're not owed a made bed but I'm hopeful that you get my point and you wouldn't interpret it as entitlement.)

A potential improvement: a very opinionated guide to esy, perhaps? I'd love to author such a guide one day (and would be delighted if somebody beats me to it).

Re: Why is my Rust build so slow?

#196

Post by pjmlp »

ModernMech wrote: post #168
pjmlp wrote: post #139

Earlier quoted context omitted.

My old dual core laptop from 2009 works just fine with Visual Studio 2022, even though I wasn't the OP. And long compile times kill the battery on the go, and cargo check hardly helps when writing GUI code.

I don’t think I follow the point you’re trying make. Are you trying to say Rust compile times are a problem for you on your 13 year old laptop in the context of writing GUI code on battery? If so I think that’s such a specific scenario that it’s hard to draw any generally applicable conclusions.

I also own devices like laptop graphics workstations.

The point I am making is Rust only for those with enough income to buy hardware powerful enough to have a usable workflow or for anyone regardless of what hardware they can afford?

As for coding on the go, classical desktops are a dying breed.

Re: Why is my Rust build so slow?

#197

Post by yawaramin »

pdimitar wrote: post #195
yawaramin wrote: post #189

Earlier quoted context omitted.

I really go and forth on this. By separating the package manager and build tool, they leave the door open for either to be swapped out (which is what esy does, incidentally). The flexibility comes at a price of complexity, but it usually works well after climbing the learning curve.

I don't disagree and you're correct, the problem is that I'm usually investing 1-2h segments in playing with OCaml once every few weeks. Having 80% of that time swallowed by a build tool leaves a sour taste. :| I get what you're saying but it applies to people who already work full time with OCaml. For guys like myself who want to periodically dip their toes and make a slow and steady progress... it makes us feel we'…

I don't take it as entitlement but more as a case of expectations not matching with reality. With 1 to 2 hrs every few weeks, it's very difficult to ramp in a meaningful way with most languages. Unless they're toy languages or unless people have spent large amounts of time/money for those use cases.

Perhaps you would be best off finding a fully set-up Docker image with a working installation of OCaml/opam, and connecting VSCode to that to act as your dev environment. That's how some educators are teaching it nowadays.

Re: Why is my Rust build so slow?

#198

Post by pdimitar »

yawaramin wrote: post #197
pdimitar wrote: post #195

Earlier quoted context omitted.

I don't disagree and you're correct, the problem is that I'm usually investing 1-2h segments in playing with OCaml once every few weeks. Having 80% of that time swallowed by a build tool leaves a sour taste. :| I get what you're saying but it applies to people who already work full time with OCaml. For guys like myself who want to periodically dip their toes and make a slow and steady progress... it makes us feel we'…

I don't take it as entitlement but more as a case of expectations not matching with reality. With 1 to 2 hrs every few weeks, it's very difficult to ramp in a meaningful way with most languages. Unless they're toy languages or unless people have spent large amounts of time/money for those use cases. Perhaps you would be best off finding a fully set-up Docker image with a working installation of OCaml/opam, and connec…

Yep, agreed again. I'll invest the proper amount of hours to not only nail an automated project bootstrapping with esy which I'll then proceed to script with bash/zsh. I'll also exercise a few paths like adding an external dependency, splitting the project to a library and binary, being able to use a REPL (`utop` I think?) in the project, etc.

After that's done I'll also document the entire thing. At that point that might make a good candidate for a blog post to enrich the OCaml ecosystem, too.

Only after that point can I play casually with it, that's true. There's always an initial ramp-up price that has to be paid and in my case that price was higher than I wanted. I'm still willing to go through it all because I absolutely love what OCaml is in every way that I've been exposed to so far (with the exception of build tooling as already said).

While I am going through this I can indeed make use of Docker images and see what they do that I failed to do before. Could be very illuminating.

Re: Why is my Rust build so slow?

#199

Post by mustache_kimono »

MuffinFlavored wrote: post #169
misnome wrote: post #75

Earlier quoted context omitted.

This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. Anyone who doesn't know about many of these tools will probably find them useful (or at least useful to know that they exist) in the future. Besides, for iteration people are probably in debug, not release mode, which the article mentions is initially 19s vs 2m+. As far as I can see the ma…

> This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. I'd argue that when it comes to doing work, I only want to deep-dive into my code. Not third party libraries that "vow" to have been tested + performant, let alone the language/build tools themselves.

I thought this level of entitlement was restricted to open source users, not devs. AFAIK Rust never promised anything re: the compile-time performance of its standard library, and I know of no 3rd party library that does. You link in a 3rd party library, then that's your code now for better or for worse.

Re: Why is my Rust build so slow?

#200

Post by UtherII »

izacus wrote: post #163
ModernMech wrote: post #128

Earlier quoted context omitted.

I teach C++ and Rust to college students, and their number one praise of Rust over C++ is how much more helpful the error messages are. It’s really night and day, so I can’t even fathom how you would equate the two.

It's easy to fathom once you go beyond the school examples and start working on bigger codebases. The error messages are verbose and simple until you hit cases where borrow checker complains about an error in a completely different part of the codebase than where the actual issue here is. This is where it behaves similar to C++ (and, honestly, some other languages) and there all the verbosity in the world doesn't hel…

Have you really used Rust on big codebases? One of the big advantage of Rust is especially that it fails far earlier than C++. Borrow checker error are local error that prevent bad behavior to propagate and cause problem on unexpected part.
Post reply on HN