Rust compiler performance • Hacker News Board

Re: Rust compiler performance

#261

Post by sapiogram » Sun, Jun 15, 2025, 6:23 PM UTC

maccard wrote: post #196

sapiogram wrote: post #82

Earlier quoted context omitted.

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] htt…

Note that `go clean` doesn't actually clear dependencies, which are stored globally. It's possible that your initial compile also wasn't a true clean compile, because some modules were already cached globally.

Re: Rust compiler performance

#262

Post by kobzol » Mon, Jun 16, 2025, 8:16 AM UTC

mlugg wrote: post #217

kobzol wrote: post #146

Earlier quoted context omitted.

I think a reasonable comparison would have to be DoD Rust parser vs current Rust parser. Comparing across languages isn't very useful, because Zig has very different syntax rules, and doesn't provide diagnostics near the same level as Rust does. The Rust compiler (and also its parser) spends an incredible amount of effort on diagnostics, to the point of actually trying to parse syntax from other languages (e.g. Pytho…

[edited to correct formatting] Your points here don't really make sense. There are many ways you can apply DoD to a codebase, but by far the main one (both easiest and most important) is to optimize the in-memory layout of long-lived objects. I won't claim to be familiar with the Rust compiler pipeline, but for most compilers, that means you'd have a nice compact representation for a `Token` and `AstNode` (or whateve…

I also don't know all the details, but the Rust parser tokens contain horrible crimes, primarily because of macros. All I wanted to say was that applying DoD to the parser in Rust would (IMO) be much more difficult than in Zig, because language differences and different approaches to error reporting. Not saying it's impossible ofc. That being said, I don't really think so much effort would be worth here, the gain would be minimal in the grand scheme of things; we have bigger perf. problems than parsing.

Re: Rust compiler performance

#263

Post by nicoburns » Mon, Jun 16, 2025, 2:54 PM UTC

majewsky wrote: post #247

nicoburns wrote: post #230

Earlier quoted context omitted.

> Unless you have perfect reproducible builds Or a trusted build server doing the builds. There is a build-bot building almost every Rust crate already for docs.rs.

docs.rs is just barely viable because it only has to build crates once (for one set of features, one target platform etc.). What you propose would 1) have to build each create for at least the 8 Tier 1 targets, if not also the 91 Tier 2 targets. That would be either 8 or 99 binaries already. Then consider that it's difficult to anticipate which feature combinations a user will need. For example, the tokio crate has 1…

You could get a lot of benefit from a much smaller subset. For example, just the "syn" crate with all features enabled on tier 1 targets (so ~8 builds total) would probably save a decent chunk off almost everybody's build.

Re: Rust compiler performance

#264

Post by codr7 » Wed, Jun 25, 2025, 4:39 PM UTC

yencabulator wrote: post #251

dvt wrote: post #109

Earlier quoted context omitted.

I like Rust, but I think this post is unfairly downvoted. Rustaceans often annoyingly point out that "you can't use super-common-footgun X with Rust!" which, while true, they also omit the compromises made are immense (frankly, compiler performance is one of them).

Nah, bringing out this argument in any thread that dares to mention whatever the commenter dislikes is just plain old off-topic. Go threads get people complaining. Rust threads get people complaining. The complaining is not a great addition to the discussion.

Does it really have to be either or?

I get the feeling that spending a lot of time in Rust makes you believe not having that kind of backup is madness.

Yet programmers all over the world get by just fine without it.

And it's not free by any means, there's a fair bit of a learning curve and increased effort involved.

Can't hurt the language to take these problems seriously, can it?