Live data from Hacker News

Why is my Rust build so slow?

fasterthanli.me

201–210 of 217 posts

Re: Why is my Rust build so slow?

#201

Earlier quoted context omitted.

You mean, by the time you split up the project into a bunch of tiny crates and mention: > I don't love how the dependency graph looks After adding this complexity to the project, yes, some of the crates are building in ~3s, if they are the only ones that needed to be rebuilt. Meanwhile, in a Java project there is none of this artificial crate splitting. Sure, Java projects have other nonsense, but they don't force yo…

It's a tradeoff: if you make the file the language's compilation unit, then you can't have "circular imports" to allow end users divide their code in an ergonomic manner with fewer "arbitrary" restrictions. We can argue all year on whether Rust settled on the right side of that trade-off.

I'm just surprised that no one has (to my knowledge, anyway) tried this even experimentally. Wouldn't the potential build speed improvement be worth at least trying out the one-file-per-crate strategy?

Re: Why is my Rust build so slow?

#202

Earlier quoted context omitted.

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

> Using a faster linker by default, e.g. Mold. Although I don't know whether there are portability or other issues here. mold supports precisely one platform: x86_64 Linux. It also doesn't support linker scripts beyond what is necessary to link libc, and given the creator honestly suggested the suckless practice of editing and recompiling the source code as a possible replacement for them I have my doubts that it'll…

mold supports not only x86-64 but also i386 and ARM64. And besides libc, it can link almost all user-land Linux programs already (I tested that by compiling all Gentoo packages with mold).

If you have to use a linker script for kennel development or embedded programming, mold doesn't work for you, though.

Re: Why is my Rust build so slow?

#203

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…

Which editor is this?

Re: Why is my Rust build so slow?

#204

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. 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'd be interested to hear what system/field/language you use with compilers that come with guarantees that they will never, ever introduce performance regressions for compile times under any circumstances (presumably with a hefty SLA to match), and where the addition of e.g. an extra innocuous header by some other part of your team will never never ever introduce unexpected nonlinear compile times that require invest…

Naturally having scons written in Python has nothing to do with it.

Re: Why is my Rust build so slow?

#205
post #92

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.

Well, in this case. It had to do with Warp hitting a regression in compiler. Spring is one of most if not THE ubiquitous piece of Java software. All Java shop I worked for, had Spring Comparing Spring+Java to Rust+Warp is imo fair game.

Meanwhile others of us have never used Spring in production, I have been on the JEE camp since the BEA and WebSphere 5.1 days.

Re: Why is my Rust build so slow?

#206

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.

For pretty 90 plus % of jobs you're pretty much confined to the Spring ecosystem. Same with C# and asp.net separating the two would be really weird.

Hello from the 10%.

Re: Why is my Rust build so slow?

#207
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…

"compiling C++ is even worse"

In my experience, this has been the other way around. C++ gives you many tools to optimise compilation and when one one takes advantage of them (precompiled headers/shared libs/no boost, etc), the edit-compile-test cycle is fairly fast.

Rust is consistently slow to compile and not much idea of how to go about optimising compile speed.

Both languages are snails compared to Go, of-course.

Re: Why is my Rust build so slow?

#208
post #146
post #78

Earlier quoted context omitted.

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.

Use Maven Daemon. (https://github.com/apache/maven-mvnd) . With Maven Daemon, traditional maven builds get a spectacular boost factor that put them ahead of Gradle. (Haven't tried Bazel though)

Re: Why is my Rust build so slow?

#209

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.

Kindly check LOC and number of dependencies of your Java App and then compare with this Rust app. Java compiles damn fast, its all the massive chain of dependencies that people keep pulling with it that is usually the issue. That and lots of annotation processing.

Avoid these things and Java is extremely fast to compile

PS: Also if you are using Maven - leverage Maven Daemon.

PPS: Languages like Go are extremely fast to compile not just because the language is simpler but also because the standard library is so good and deep that deps are not needed.

Re: Why is my Rust build so slow?

#210

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.

PR to stabilize -Ztimings as --timings: https://github.com/rust-lang/cargo/pull/10245
Post reply on HN