Rust compiler performance • Hacker News Board

Re: Rust compiler performance

#191

Post by goodpoint » Fri, Jun 13, 2025, 12:03 PM UTC

WhyNotHugo wrote: post #95

norir wrote: post #27

Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture. Rust can likely never be rearchitected without causing a disastrous schism in the community,…

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.

That's solved with sccache but even with that compilation time is still garbage

Re: Rust compiler performance

#192

Post by superkuh » Fri, Jun 13, 2025, 12:05 PM UTC

The biggest problem with the Rust compiler is not it's speed in compiling. It's that rustc from 3 months ago can't compile most Rust code written today. And don't tell me that cargo versioning fixes this, it doesn't. The very improvements we are celebrating here, which are very real and appreciated, are part of this problem. Rust is young and Rust changes very, very fast. I think it'll be a great language in a decade when it's no longer just used by bleeding edge types and has a target that stands still for more than a few months.

Re: Rust compiler performance

#193

Post by zozbot234 » Fri, Jun 13, 2025, 12:07 PM UTC

baalimago wrote: post #182

diggan wrote: post #179

Earlier quoted context omitted.

> I don't see how there could be people dedicated to work on an issue as grand as this in Rust's current organizational form You're getting half ways there of giving actionable feedback, what exactly is the problem with the current organization structure that would prevent any "grand" issues like these? Is there a specific point in time when you felt like Rust stopped being able to work on these grand issues, or it h…

>what exactly is the problem with the current organization structure that would prevent any "grand" issues like these? Well, it's summarized quite well here: >"Performing large cross-cutting changes is also tricky because it will necessarily conflict with a lot of other changes being done to the compiler in the meantime. You can try to perform the modifications outside the main compiler tree, but that is almost doome…

This is a concern for any fast-moving project, i.e. it's a good problem to have! You can work on your modifications on a side branch and then forward port them to the current state of main before proposing them for merge, it will probably be less work overall.

Re: Rust compiler performance

#194

Post by maccard » Fri, Jun 13, 2025, 12:13 PM UTC

Fluorescence wrote: post #74

maccard wrote: post #60

Earlier quoted context omitted.

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 li…

> clean build of a few thousand lines of rust took close to 10 minutes That doesn't sound likely. I would expect seconds unless something very odd is happing. Is the example symbolicator? I can't build the optional "symbolicator-crash" crate because it's not rust but 300k of C++/C pulled from a git submodule that requires dependencies I am not going to install. Your complaint might literally be about C++! For the res…

> That doesn't sound likely. I would expect seconds unless something very odd is happing.

And yet here we are.

There are plenty of stories like this floating around of degenerate cases of small projects. Here's [0] one example with numbers and how they solved it. There are enough of these issues that by getting bogged down in "well technically it's not Rust's fault, it's LLVM's single threadedness causing the slowdown here" ignores the point - Rust (very fairly) has a rep for being dog slow to compile even compared to large C++ projects

> For the rest of the workspace, 60k of rust builds in 60 seconds

That's... not fast.

https://github.com/buildkite/agent is 40k lines of go according to cloc, and running `go build` including pulling dependencies takes 40 seconds. Without pulling dependencies it's 2 seconds. _That's_ fast.

[0] https://www.feldera.com/blog/cutting-down-rust-compile-times...

Re: Rust compiler performance

#195

Post by maccard » Fri, Jun 13, 2025, 12:14 PM UTC

jason-johnson wrote: post #177

maccard wrote: post #60

Earlier quoted context omitted.

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 li…

Can you say what your development environment was like? I was having 15 minute build times for a pretty small system. Everyone talks about how slow Rust compile times are so I thought that's just how it is. Then, by chance, I ended up building from a clean install on my work laptop and it took about 3 minutes from scratch. My development environment is VS Code running in a Dev container in docker desktop. So after my…

Cargo in vscode on windows on a monstrously big machine (3990x/128GB RAM/NVMe drive, Gigabit Ethernet)

I think if it's that sensitive to environment issues, that solidifies the point that there are major problems that lots of people are going to have.

Re: Rust compiler performance

#196

Post by maccard » Fri, Jun 13, 2025, 12:18 PM UTC

sapiogram wrote: post #82

maccard wrote: post #60

Earlier quoted context omitted.

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 li…

Thanks for actually including the slow repo in your comment. My results on a Ryzen 5900X: * Clean debug build: 1m 22s * Incremental debug build: 13s * Clean release build: 1m 51s * Incremental release build: 24s Incremental builds were done by changing one line in creates/symbolicator/src/cli.rs. It's not great, but it sounds like your experience was much worse for some reason.

For reference, buildkite-agent [0] is about 40k lines of go. Running `go build` including dependencies took 40 seconds, and running `go clean && go build` took 2 seconds. I know Go and Rust aren't comparable, but Rust's attitude appears to be "we don't really care" when you compare it to Go, considering they both started at _roughly_ the same time and Rust's first stable release came long after Go was in use.

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

Re: Rust compiler performance

#197

Post by littlestymaar » Fri, Jun 13, 2025, 12:31 PM UTC

ninkendo wrote: post #187

littlestymaar wrote: post #186

Earlier quoted context omitted.

You answer your own argument here: > Does this mean I’m “vetting” all the code I depend on? Of course not. Inspecting public facing parts of the code is one thing, finding nasty stuff obfuscated in a macro definition or in a Default or Debug implementation of a private type that nobody is ever going to check outside of auditors is a totally different thing. > My IDE (rustrover) has “follow symbol” support I don't kno…

The point of my argument is not to say I’m vetting anything, but to say that there are tons of eyeballs on crates today, because of the fact that they are distributed as source and not a binary. It’s not a silver bullet but every little bit helps, every additional eyeball makes hiding things harder. The original claim is that “pretty much no one” reads any of their dependencies, in order to support a claim that they…

> The original claim is that “pretty much no one” reads any of their dependencies,

No the claim is that very few people read the dependencies[1] enough to catch a malicious piece of code. And I stand by it. “Many eyeballs” is a much weaker guarantee when people are just doing “go to definition” from their code (for instance you're never gonna land on a build.rs file this way, yet they are likely the most critical piece of code when it comes to supply chain security).

[1] (on their machines, that is if you do that on github it doesn't count since you have no way to tell it's the same code)

Re: Rust compiler performance

#198

Post by kjuulh » Fri, Jun 13, 2025, 12:34 PM UTC

crohr wrote: post #178

kjuulh wrote: post #171

Could Rust be faster, yes. But honestly, for our use-case shipping; tools, services, libraries and what have you in production, it is plenty fast. That said, Rust definitely falls off a cliff once you get to a very large workspace (I'd say plus 100k lines of code it begins to snowball), but you can design yourself out of that, unless you build truly massive apps. Incremental builds doesn't disrupt my feedback loop mu…

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

You can rent bigger runners from github. They're still not as fast as third party ones, but it takes 5 minutes to set up and is still pay as you go. I just see a lot of people use the default ones, which are very small.

Re: Rust compiler performance

#199

Post by jplusequalt » Fri, Jun 13, 2025, 12:51 PM UTC

sagarm wrote: post #132

jplusequalt wrote: post #128

Earlier quoted context omitted.

I think you're missing the point of my comparison. Rust has a lot more going on than Go, so it feels unfair.

Go has a lot less going on than Rust partially because compile times were a priority.

Rust has long compilation times because the borrow checker was a priority.

They're very different languages.

Re: Rust compiler performance

#200

Post by kibwen » Fri, Jun 13, 2025, 1:06 PM UTC

zozbot234 wrote: post #126

kibwen wrote: post #124

Earlier quoted context omitted.

Indeed, an alloca-heavy ABI was what I proposed, and I'm aware that the Rust devs have backed away from unsized locals, but these are unrelated. I was never totally clear on the specific LLVM-related problem with the former (it can't be totally insurmountable, because Swift), but people more knowledgeable in LLVM than I seemed uneasy about the prospect. As for the latter, it's because the precise semantics of unsized…

Why does it have to be soundly specified though? Why not just provide an unsafe feature that works the same as existing C/LLVM, and "leave no room for a lower-level language"? The safe featureset around it can always come later if the issues around how to specify it are worked out.

The difficulty is that `unsafe` doesn't mean "yolo", it means "there are memory safety invariants here that you, the programmer, must manually uphold", so we still need to consider what those invariants would be. I'm sure that Ralf Jung would be happy to talk more about this if anyone has any ideas for how to move forward:

"With #111374, unsized locals are no longer blatantly unsound. However, they still lack an actual operational semantics in MIR -- and the way they are represented in MIR doesn't lend itself to a sensible semantics; they need a from-scratch re-design I think. We are getting more and more MIR optimizations and without a semantics, the interactions of unsized locals with those optimizations are basically unpredictable. [...] If they were suggested for addition to rustc today, we'd not accept a PR adding them to MIR without giving them semantics. Unsized locals are the only part of MIR that doesn't even have a proposed semantics that could be implemented in Miri. (We used to have a hack, but I removed it because it was hideous and affected the entire interpreter.) I'm not comfortable having even an unstable feature be in such a bad state, with no sign of improvement for many years. So I still feel that unsized locals should be either re-implemented in a well-designed way, or removed -- the current status is very unsatisfying and prone to bugs."

https://github.com/rust-lang/rust/issues/48055#issuecomment-...