Solving Rust’s biggest problem

Unveiling the most significant improvement to the Rust compiler yet. Witness how Rust is overcoming it's compilation hurdles and solidifying its position as a top-tier programming language.

[OrbitalCookie]

Slow build aren't because of rust "carefully checking the program". You can use "cargo check" and see how fast that is. It's slow because of colossal pile of unoptimized intermediate code it dumps on LLVM and says "here buddy, have fun, I know you are good at this". Problem is exacerbated by any use of generics or smart macros. Try to use small alternatives for clap and serde_json, and you will see huge improvement to compile times.

Since this comment has blown up, this was what I remembered from the olden rust days. Now there is MIR representation in the compiler with possible optimizations before the LLVM.

[MichaelZimmermann]

0:50 "when people complain about slow builds, they're almost always talking about the slow release build" Do you have a source for that? Because it surprises me a lot. I only care about debug build times because they need to be done often. Release builds are done rarely and run in CI so I don't really care how long they take.

[pcfreak]

Sure it takes long to compile, but do you rather scroll Facebook waiting for the build to finish or do you want to chase a bug down a rabbit hole, trying to figure out why some variable is undefined?

[perfectionbox]

instead of rustc the compiler could have been called crust 🤣

[weirdalchemy]

"Eats personal time" No shot I'm letting compile time eat my personal time. Shit compiles on the clock.

[_Aarius_]

I am working on a perf critical app at work, in Rust, so even my dev/debug has to use release optimisations so I can find regressions immediately. Compile times suck lmao

[Jiftoo]

The parallel frontend is consistently slower on (most) of my personal projects, by about one or two seconds.
The only time it was actually faster for me is building the tokio repo (about a second of improvement in debug and half a second in release).
I guess it only speeds things up in niche situations, like workspace builds(?)

[adsick_ua]

"compilation time decreased from about ten seconds (9.57)
to about eight seconds (8.28)"
you sound like it's 2 sec improvement whereas it's actually 1.29 sec, dude. don't be like that, off by 47%

[exciting-burp]

Cranelift is going to be a bigger boost. LLVM is one of the slowest parts of the compiler. The biggest issue _by far_ is the use of ld, you can get a significant boost by configuring lld (or mold) today.

[MiesvanderLippe]

Alternatively, think more and compile less. It is not Python :)

[isaaclyman]

They should rewrite the compiler in Rust. Then it would be super fast and completely memory sa—*I walk face first into a sliding glass door*

[CKidder]

Honestly, this is a tempest in a teakettle. I could not care less about how long it takes to compile. Make Hello World take 30 seconds if that means the compiler does a great job, checks the code thoroughly, and the resulting executable is as optimized as possible. The compile time is the least of my worries. I'd like my programs to work properly and quickly. That's the #1 goal. Compile speed is cool and all but that worry comes after most everything else. So, I think Rust got it right. It checks programs thoroughly, it tries to optimize well. After that's all said and done, sure, let's get it compiling faster too. But, calling that it's biggest problem is actually a GREAT sign. If we're down to "it takes 10 seconds too long to compile" then obviously things are in excellent shape.

[oefzdegoeggl]

Building a large program in "Borland C++ 1.0" was a pain in the ass compared to the then super-fast TurboPascal. I don't find rusts's debug compile times thaaat dramatic. For release, yes, especially with LTO turned on. But I do release build when ... well, releasing only, so not a big issue for me.

[dirac]

As long as they don't sacrifice some runtime performance for conpile-time fastening, I'm ok with the new improvement. I always set `codegen-units` to `0`.

[theelmonk]

We used to have slow compile times for *everything*. This was a real pain for C because the compiler is bad at getting out of sync and producing spurious errors. You could analyse the messages so far and then they became meaningless.

So there was a tendency to fix the first error or two then recompile and re-evaluate. This avoided wasting time fixing errors that were really only parse failures.

Now if you have better error messages due to more static typing and less loss of sync, it's worth considering more of the reported errors before giving up and recompiling. This increases productivity by getting more work done in the edit phase and requiring less compile cycles.

Does Rust provide this advantage ? if you work differently, do you get similar edit/compile time ratios that you would with fast compilation ?

Also, remember xkcd:303

[luquini]

tell me if I'm wrong.
I have a REST API made with Actix and SQLx. It builds in... 10 seconds max.
I never saw it as an issue. I can check my email, change the music, make myself a coffee, etc.
It's a real problem for you guys? or you are experiencing larger building times?

[rusmemes]

I do not understand this problem at all.
Why not having a cup of coffee (tea|bear|vodka|whatever you like) while compilation process???

[SimoLPers]

Why does this feel like a dejavu?
Is this a reupload by any chance?

[theLowestPointInMyLife]

I was excited to hear about this a while ago but upon trying it out, the threaded option is actually slower than single threaded.

24 core Ryzen 5900x
normal: 23.4s
threads: 26.8s

the results are very consistent, around 15% slower with threads

[MikeM]

I would have preferred if you tried a Bevy hello world fresh compile. That takes about 5 minutes on my computer.