Rust compiler performance (kobzol.github.io)

Not only language.

Many of complaints towards Rust, or C++, are in reality tooling complaints.

As shown on other ecosystems, the availability of interpreters or image based tooling are great ways to overcome slow optimizating compilers.

C++ already had a go at this back in the early 90's with Energize C++ and Visual Age for C++ v4, both based on Common Lisp and Smalltalk from their respective owners.

They failed on the market due to the hardware requirements for 90's budgets.

Now slowly coming back with tooling like Visual C++ hot reload improvements, debugging optimised builds, Live++, Jupiter notebooks.

Rational Software started their business selling Ada Machines, the same development experience as Lisp Machines, but with Ada, lovely inspired on Xerox PARC experience with Mesa and Mesa/Cedar.

Haskell and OCaml, besides the slow compilers, have bytecode interpreters and REPLs.

D has the super fast dms, with ldc and gdc, for the optimised builds suffering from longer compile times.

So while Rust cannot be archited in a different way, there is certainly plenty of room for interpreters, REPLs, not compiling always from source and many other tooling improvements, within the same language.

It's certainly possible to think of language features that would preclude trivially-achievable high-performance compilation. None of those language features that are present in Rust (specifically, monomorphized generics) would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.

This was a big reason for dart canceling its previous macros attempt (as I understand it). Fast compilation is integral for Flutter development - which accounts for a late percentage of dart usage - so after IIRC more than two years of developing it they still ended up not going through with that iteration of macros because it would make hot reload too slow. That degree of level-headedness and consideration is worthy of respect IMO.

One of the issue why compile times are so awful is that all dependencies must be compiled for each project.

20 different projects use the same dependency? They each need to recompile it.

This is an effect of the language not having a proper ABI for compiling libraries as dynamically loadable modules, which in itself presents many other issues, including making distribution of software a complete nightmare.

At some point, the community is also responsible for the demanding expectation of a "not slow" compiler.

What's "slow"? What's "fast"? It depends. It depends on the program, the programmer, his or her hardware, the day of the week, the hour of the day, the season, what he or she had for lunch, ...

It's a never ending quest.

I, for exemple, am perfectly happy with the current benchmark of the rust compiler. I find a x2 improvement absolutly excellent.

The key to unlocking a 10x improvement to compilation speeds will like be multithreading. I vaguely remember that LLVM struggled with this and I am not sure where it stands today. On the frontend side language (not compiler) design will affect how well things can be parallelized, e.g. forward declatations probably help, mandatory interprocedural anaylyses probably hurt.

Having said that, we are in a bad shape when golang compiling 40kLOC in 2s is a celebrated achievement. Assuming this is single threaded on a 2GHz machine, we 2s * 2GHz / 40kLOC = 100k [cycles] / LOC

That seems like a lot of compute and I do not see how this cannot be improved substantially.

Shameless plug: the Cwerg language (http://cwerg.org) is very focussed on compilation speeds.

It is ironic how “rewrite it in Rust” is the solution to make any program fast, except the Rust compiler.

maybe rustc will never be re-architectured (although it has already been rewritten once), but with developing rust standard there will come new Rust implementations. And there is a chance that they will prioritize performance when architecting.

If the application works poorly for the developers it will eventually work poorly for everyone.

Being surrounded by suck slowly creeps into the quality of your work.

Computer programming is the only skilled labor I know of where people eschew quality tools and think they won’t output slop by doing so.

You're conflating language design and compiler architecture. It's hard to increment on a compiler to get massive performance improvement, and rearchitecture can help, but you don't necessarily need to change anything to the language itself in that regard.

Roslyn (C#) is the best example of that.

It's a massive endeavor and would need significant fundings to happen though.

[flagged]

I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives.

Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take.

On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was.

[0] https://github.com/getsentry/symbolicator

[1] https://github.com/buildkite/agent

>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust

I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness.

When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.

Makes sense to me! Everyone with enough C++ experience has dealt with that nightmare at one point. Never again, if you can help it.

It is a quantifiable negative to which you can always point. Of course it will be used for justifications.

There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.

The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.

C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest.

* It's not beating interpreted languages any time soon, but that's not really a fair comparison.

"Hand-rolled assembly" was one item in a list that also included DoD. You're reading way more into that sentence than they wrote- the claim is that DoD itself also impacts the maintainability of the codebase.

I was working on a zig project recently that uses some complex comptime type construction. I had bumped to the latest dev version from 0.13, and I couldn't believe how much improvement there has been in this area. I am very appreciative of really fast iteration cycles.

Yeah but it's Zig. Rust is for when you want to write C but have it be easier. Zig is when you want it to be harder than C, but with more control over execution and allocation as a trade off.

>And it looks even more dire when you want to add clang-tidy in the mix. It can take like 5 solid minutes to lint even small projects.

And running all tests with sanitizers, just to get some runtime checks of what Rust excludes at compile time.

I love Rust for the fast compile times.

why do you run clang-tidy with compiler? Just use it interactively - with cland. These is much more useful to me

Yeah definitely when you include dependencies. Also I've noticed that when your dependency tree gets above a certain size you end up pulling in every alternative crate for a certain task, because e.g. one of your dependencies uses miniz_oxide and another uses zlib-rs (or whatever).

On the other hand the compile to for most dependencies doesn't matter hugely because they are easy to do in parallel. It's always the last few crates and linking that take half the time.

This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?

Not to be that guy who comes to Rust’s defense whenever Go is mentioned, but... Rust protects from a much larger class of errors than just memory safety. For instance, it is impossible to invalidate an iterator while iterating over it, refer to an unset or invalid value, inadvertently merely shallow copy a variable, or forget to lock/unlock a mutex.

Could you elaborate on the memory issues in all four languages that you ran into?

What kind of CI runners do you use then? Do you self-host?

When a platform has good support and is easy to onboard this is the inevitable result. It's just like the JavaScript ecosystem.

But this is not a downside. Just like I can start a new website project and not use a single dependency, I can start a new rust project and not install a single dependency.

To me the real value is in the tools and core language feature. I could probably implement my own minimal ad-hoc async IO framework if I wanted to, and shape it to my needs. No dependencies.

I don't know, these things ebb and flow.

There's a bit of pushback against high-dependency project structures and compile times recently, and even niche crates like `unsynn` have garnered some attention as an alternative to the relatively heavy `syn` crate.

For many use-cases yes, but there are crates bottlenecked on different things than the codegen backend.

But I don't think that's the point. We could get rid of LLVM and use other backends, same as we could do other improvements. The point is that there are also other priorities and we don't have enough manpower to make progress faster.

This is somewhat true but also a bit misleading. Lot of the problems comes from how rust interacts with it, and how are rust projects structured. This ultimately shows up as time in LLVM, but LLVM is not entirely responsible for it.

A minute is pretty bad. I understand it may work for your use case, but there are plenty of use cases out there where errors typically don't fail the compile and a minute iteration time is a deal killer. For instance: UI work - good luck catching an incorrect color with a compile error. Vite can compile 40,000 loc and display it on your screen in probably a couple of milliseconds.

But how big are your big projects?

> I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.

Rust is in the process of building out the cranelift backend. Cranelift was originally built to be a JIT compiler. The hope is that this can become the debug build compiler.

https://github.com/rust-lang/rustc_codegen_cranelift

The JVM is not a very meaningful target for Rust since it does not use C-like flat memory addressing and pointer arithmetic. It's as if every single Java object and field is sitting in its own tiny memory segment/address space. On the one hand, this makes it essentially transparent to GC, which is a key property for Java; OTOH, it means that compiling C-like languages to the JVM is usually done by reimplementing "memory" as a JVM array of byte values.

LLVM optimizations are the overwhelming majority of the compilation bottleneck for us over at Feldera. We blogged about some of the challenges we faced here: https://www.feldera.com/blog/cutting-down-rust-compile-times...

We almost definitely need to build a JIT in the future to avoid this problem.

I would love this in modern languages.

For dev builds, I see JIT compilation as a better deal than debug builds because it's capable of eventually reaching peak performance. For performance sensitive stuff like games, it really matters to keep a nice feedback loop without making the game unusable by turning off all optimizations.

AOT static binaries are valuable for deployments.

No idea how expensive it would be to develop for an existing language like Rust though.

You have a fair point, I agree that while compiler performance is a priority, is is one of many priorities, and not currently super high on the list for many Rust Project developers. I wish it was different, but the only thing we can do is just do the work to make it faster :) Or support the people that work on it.

Isn't Vite for javascript though, which is, of course, a scripting language?

Btw, I've used QML and Dioxus with rust (not for games). Both make hot reloading the GUI parts possible without recompiling since that part is basically not rust (Dioxus in a bit more limited manner).

cargo check exists for option 1. For 2.) it depends on the project structure. Either way, they don't help as much as you would hope for.

You don't even need to ask AI to get an answer to the first question, the first hit on both Google and Bing will tell you how to do it - it takes 2 seconds!

Maybe it has been, but said bigger company hasn't published their work?

I disagree fast compile times are "required" for the professional market btw. They are nice, sure, but there's plenty of professional development out there in languages that are slow to compile.

> bigger company, who have the time and resources to specialize it into something which fits better into a professional market

Welcome to the central thesis for using Microsoft's stack.

If I'm getting paid money based upon the direct outcome of my work (I.e., freelance / consulting / 1099), I am taking zero chances with the tooling. $500 for a perpetual license of VS the cheapest option by miles if you value your time and sanity.

Iteration time is nice, but the debugger experience is the most important thing once you are working on problems people are actually willing to pay money to solve. Just because it's "possible" doesn't mean it is ergonomic or accessible. I don't have to exit my IDE if I want to attach to prod and run a cheeky snippet of LINQ on a collection in break mode to investigate a runtime curiosity.

(OP) I submitted this some time ago, and am pretty sure I would have submitted the title as is, so I'm guessing some manual or automatic editing since by the mods before the second chance here.

I'm not sure how that works. You either let the compiler compile your whole program with AVX (which duplicates the binary) or you manually use AVX with runtime detection on selected places (which requires writing manual vectorization).

Yes but are these the default? I want this to work pleasantly out of the box so we don't scare new users as quickly.

I don't think we hit a bedrock. As I wrote, we have a lot of ideas for massive improvements. But we need more people to work on them.

It's OK; 20 years ought to be enough time to rewrite LLVM in Rust.

The previous post on the OP's blog is about exactly this: https://kobzol.github.io/rust/rustc/2025/06/02/reduce-cargo-...

The problems are largely related. Cut down the amount of intermediate compilation artifacts by half and you'll have sped up the compiler substantially. Monomorphization and iterator expansion and such is a significant contributor to both issues.

One of the reasons I quit rust is literally because having 4-5 projects checked out that use serde would fill my laptop drive with junk in a few weeks.

Why not both?

If I had to choose though, I would choose compilation speed. Buying an SSD to double my storage is much more cost effective than buying a bulkier processor to halve my compilation times.

Is this not more a Cargo thing? Cargo is obsessed with correct builds and eventually the file system fills up with old artifacts.

(I know, I have to declare Cargo bankruptcy every few weeks and do a full clean & rebuild)

Not that this isn't a problem, it is, target folders currently take up ~100gb on my machine but...

I'd still, by far, prefer a tiny incremental compile speed increase over a substantial storage reduction. I can get a bigger SSD, I can't get my time back :'(

This is one of the only reasons I disliked Haskell. GHC and lib files can easily take over 2GB of storage.

What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?

Performance has been worked on since Rust 1.0 or so, for all this time, there has been lots of work on compiler performance. There's no "before performance" :)

I think there is a massive difference in compile times between idiomatic C and C++, so its problematic to be lumping them together. But there is also some selection bias since large projects tend to migrate from C to C++.

I'm worried this person is going to experience a Yak overflow, honestly.

Kobzol is an absolutely wonderful person to work with. I also work in the Rust project, and any time I've interacted with him, he's been great.

Talk about proper `continuous improvement`