Live data from Hacker News

Why is my Rust build so slow?

fasterthanli.me

141–150 of 217 posts

Re: Why is my Rust build so slow?

#141
post #29

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…

I would expect the stability guarantee to cover outputting _something_ human-readable, and that's it. If you want to parse the output, I would scope that under a separate feature such as `-Z timings-json`. This is similar to error messages, where the colorized output and text can change at any time, but tools can pass a flag to get stable JSON output.

Re: Why is my Rust build so slow?

#142
post #46

Earlier quoted context omitted.

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.

The worst error message was basically no error message. After I made some big refactoring to my project, cargo would just exit with:

   error: could not compile `the_project`.
And nothing else. No hint of what the problem is.

It then took me a long time to try to comment out code here and there to find out what was causing the error.

When I finally found out the problem, I took the time to fill a bug report. I don't know if anyone looked at it. https://github.com/rust-lang/rust/issues/73026

Re: Why is my Rust build so slow?

#143
post #130

"In another language, say, C or C++, we might write a Makefile by hand. What? No. Nobody does that anymore." Oh these Rustaceans or how they call themselves. Look at the gaming industry, if you're playing any AAA/AA game it's most likely C++, there's some market share on C# (where Unity is used), but still the whole gaming industry is C++, and it's bigger than movie/music industries combined. So yes, people "do that"…

I think the OP meant no one writes Makefiles manually; you might use CMake or ninja, for example.

What an odd (and demonstrably false) thing for the OP to say, Makefiles are a delight.

Re: Why is my Rust build so slow?

#144

Earlier quoted context omitted.

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

Here's my edit-compile-run cycle in dev configuration: https://streamable.com/az397y I use Qt, boost, lots of templates. - clang as a compiler - mold as a linker - PCH (easy with cmake) - plugin architecture for the software ; plugins are dynamic libraries when developing (everything is linked statically for releases which take of course much longer to build with lto, etc.) - building on Linux (it's seriously slower…

Disabling Windows Defender in your build directories can be a serious boost. NTFS is still slow, though.

Re: Why is my Rust build so slow?

#145

Earlier quoted context omitted.

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.

The worst error message was basically no error message. After I made some big refactoring to my project, cargo would just exit with: error: could not compile `the_project`. And nothing else. No hint of what the problem is. It then took me a long time to try to comment out code here and there to find out what was causing the error. When I finally found out the problem, I took the time to fill a bug report. I don't kno…

Thank you for the great report. It indeed seems to have fallen through the cracks, with no one touching it (it's missing the T-compiler tag, which means I didn't triage it) since it was first cathegorized.

I wouldn't call that lack of output representative of the experience of using rustc though, if I'm allowed to let my pride on my work flare up a bit.

Re: Why is my Rust build so slow?

#146
post #78
post #62

Earlier quoted context omitted.

> they definitely never felt too long, compared to say Java. Woah... now I am the one who have to ask: what the hell are you on about?? I work on Rust and Java projects, if you exclude running tests, Java compiles very very fast compared to pretty much any language... Rust is a lot slower to compile even on the much smaller projects I've worked on... in this post, a very small project (I think it's like 16,000 LoC, i…

And I've worked on large Java projects. Things that have like 420+ dependencies (spring boot + some other requirements). I timed the maven clean compile. And it takes around 2min.

Maven is very slow. Gradle and Bazel avoid doing wasteful things like Maven does so generally are a lot faster... if you want to know the speed of compiling Java you should just run `javac`, assuming Maven speed is Java compilation speed is far from correct even if a lot of projects still use Maven to build Java projects.

Re: Why is my Rust build so slow?

#147

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…

The two biggest time savings where accomplished by using a version without the regression bug, and using incremental builds in debug mode for local dev. Bugs can be introduced in any language, so the only gotcha to be fixed is that maybe incremental compile should be the default.

Note that incremental builds are the default for debug builds.

For reasons that are not entirely elaborated in the article, the author is using release builds for local development.

Re: Why is my Rust build so slow?

#148

I came from java and compared to that even our slowest rust build time is faster than I have ever experienced in java. I remember we had a Java springboot application who had a buildtime of 8 minutes on my 2015 MacBook. I am so happy I don't have to deal with this anymore.

Java refugees represent!

Re: Why is my Rust build so slow?

#149
post #16

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?

You are right. There is no technical reason it should be as slow as it is. It's just that not enough resource was spent to make it fast. I mean, if this were a higher priority, Rust issue #26600 would have been fixed years ago. https://github.com/rust-lang/rust/issues/26600

> Currently, GlobalISel is within 1.5 the speed of FastISel according to https://llvm.org/docs/GlobalISel/index.html and they have some ambitions for getting it within 1.1 or 1.2 in time, so it seems likely that GlobalISel will close this issue before FastISel grows the relevant support.

Heh

Re: Why is my Rust build so slow?

#150

I came from java and compared to that even our slowest rust build time is faster than I have ever experienced in java. I remember we had a Java springboot application who had a buildtime of 8 minutes on my 2015 MacBook. I am so happy I don't have to deal with this anymore.

The funny thing is you are also paying at runtime in Java for all the memory management.
Post reply on HN