11 ms·

Rust compiler performance

287 points by mellosouls 1y ago

dboreham 1y ago
I'd vote for filesystem space utilization to be worked on before performance.
- kzrdude 1y ago
  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" :)
  - estebank 1y ago
    There are multiple avenues to improve both first and incremental compiles. They "just" require large architectural changes that may yield marginal improvements, so it's hard to get those projects off the ground. But after the last project all-hands I do expect at least one of these to be pursued, of not more. There are cases where cargo recompiles crates "unnecessarily", cargo+rustc could invert the compilation pyramid to start at the root and then only compile reachable items (similar effect to LTO, but can produce a binary if an item with a compile error isn't evaluated, improving clean compiles), having better communication with linkers and having access to incremental linking would be a boon for incremental compiles, etc.
- stevedonovan 1y ago
  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)
  - vlovich123 1y ago
    Correct builds != never running garbage cleanup. I would settle for it evicting older variants of a build (I also dislike the random hash that’s impossible to determine what specifically is different between two hashes / which one is newer).
    - mbrubeck 1y ago
      Automatic garbage collection of old build artifacts* is coming in Rust 1.88 (currently on the beta channel, will become the new stable release in two weeks): https://github.com/rust-lang/cargo/issues/12633 https://github.com/rust-lang/cargo/issues/12633 *EDIT: For now this only deletes old cached downloads, not build artifacts. Thanks epage for the correction below.
      - vlovich123 1y ago
        That’s as an additional flag and not the default?
        mbrubeck 1y ago
        In versions earlier than 1.88, garbage collection required the unstable -Zgc flag (and a nightly toolchain). But in 1.88 and later, automatic garbage collection is enabled by default.
      - epage 1y ago
        That is not for build artifacts but global caches like for `.crate` files but its a stepping stone.
        mbrubeck 1y ago
        Oops, thanks for the correction.
  - epage 1y ago
    A little of both. Incremental compilation cache is likely the single largest item in the target directory but it gets cleaned up on each invocation so it doesn't scale in size with time. I believe the next release will have a cache GC but only for global caches (e.g. `.crate` files). I'd like us to at least cleanup the layout of the target directory so its easier to track stuff before GCing it. Work is underway for this. A cheap GC we could add earlier is for artifacts specific to older cargo versions.
- dralley 1y ago
  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.
- scripturial 1y ago
  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.
- ivanjermakov 1y ago
  This is one of the only reasons I disliked Haskell. GHC and lib files can easily take over 2GB of storage.
- MeetingsBrowser 1y ago
  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.
  - estebank 1y ago
    > Why not both? For better and worse, the Rust project is a "show-up-ocracy": the work that gets done is the one that volunteers (or paid employees from a company donating their time to the project) spend time doing. It's hard in open source projects to tell people "this is important and you must work on it", but rather you have to convince people that it is important and have to hope they will have the time, inclination and skill to work on it. FWIW, people were working on the cargo cache GC feature years ago[1], but I am not aware of what the current state of that is. I wouldn't be surprised if it wasn't turned on because there are unresolved questions. 1: https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning/ https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning/
    - Ygg2 1y ago
      > For better and worse, the Rust project is a "show-up-ocracy" So it's an OSS project?
      - windward 1y ago
        Linux and GCC are OSS projects but CPU companies pour work into their development because it's a strict requirement of being able to sell their products.
        pjmlp 1y ago
        Just like Amazon, Microsoft and Google nowadays pour work into Rust.
- preciousoo 1y ago
  What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?
  - jakkos 1y ago
    You can: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
    - preciousoo 1y ago
      Oh this is amazing, looks simple to set up too. Thanks!
      - kstrauser 1y ago
        It's a game-changer, especially on my slower machines like Raspberry Pis. They can use every advantage they can get.
  - epage 1y ago
    That work is being tracked in https://github.com/rust-lang/cargo/issues/5931 https://github.com/rust-lang/cargo/issues/5931 Someone has taken up the work on this though there are some foundational steps first. 1. We need to delineate intermediate and final build artifacts so people have a clearer understanding in `target/` what has stability guarantees (implemented, awaiting stabilization). 2. We then need to re-organize the target directory from being organized by file type to being organized by crate instance. 3. We need to re-do the file locking for `target/` so when we share things, one cargo process won't lock out your entire system 4. We can then start exploring moving intermediate artifacts into a central location. There are some caveats to this initial implementation - To avoid cache poisoning, this will only items with immutable source that and an idempotent build, leaving out your local source and stuff that depends on build scripts and proc-macros. There is work to reduce the reliance on build scripts and proc-macros. We may also need a "trust me, this is idempotent" flag for some remaining cases. - A new instance of a crate will be created in the cache if any dependency changes versions, reducing reuse. This becomes worse when foundation crates release frequently and when adding or updating a specific dependency, Cargo prefers to keep all existing versions, creating a very unpredictable dependency tree. Support for remote caches, especially if you can use your project's CI as a cache source, would help a lot with this.
- jakkos 1y ago
  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 :'(
- kibwen 1y ago
  The previous post on the OP's blog is about exactly this: https://kobzol.github.io/rust/rustc/2025/06/02/reduce-cargo-target-dir-size-with-z-no-embed-metadata.html https://kobzol.github.io/rust/rustc/2025/06/02/reduce-cargo-...
vlovich123 1y ago
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. I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.
- dhruvrajvanshi 1y ago
  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.
  - pjmlp 1y ago
    That approach is what you get in Common Lisp, Eiffel, Oberon language family, Java, .NET, Julia (getting there), Haskell, OCaml, C++ (with something like ROOT or C++/CLI). So if enough people care for Rust, it is also possible.
- zozbot234 1y ago
  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.
- bbatha 1y ago
  > 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 https://github.com/rust-lang/rustc_codegen_cranelift
jplusequalt 1y ago
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
- logicchains 1y ago
  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.
  - MeetingsBrowser 1y ago
    There are things you can do for Rust if it really is a deal breaker. Dioxus has a hot reload system. Some rust game engines have done similar things.
    - jplusequalt 1y ago
      When in doubt, manually patch your dll's
  - kibwen 1y ago
    You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize. To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
    - pjmlp 1y ago
      You certainly cannot distribute binary libraries, including pre-expanded templates for common use cases. Which is always my standard approach to fast build times in C++ projects.
- 0cf8612b2e1e 1y ago
panstromek 1y ago
The original title is: Why doesn't Rust care more about compiler performance?
- mellosouls 1y ago
  (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.
norir 1y ago
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, so it seems probable that compilation will always be slow.
- awestroke 1y ago
  [flagged]
  - MeetingsBrowser 1y ago
    The original comment is mostly inline with the article. All the easy local optimizations have been done. Even mostly straightforward compiler wide changes take a team of people multiple years to land. Re-architecting the rust compiler to be faster is probably not going to happen.
    - kibwen 1y ago
      > Re-architecting the rust compiler to be faster is probably not going to happen. This is a statement without the weight of evidence. The Rust compiler has been continually rearchitected since 1.0, and has doubled its effective performance multiple times since then.
      - MeetingsBrowser 1y ago
        I'm going off of what is in the article. > The second way forward is performing massive changes and/or refactorings to the implementation of the compiler. However, that is of course challenging, for a number of reasons. > if you change one thing at the “bottom” layer of the compiler, you will then have to go through hundreds of places and fix them up, and also potentially fix many test cases, which can be very time-consuming > You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail. Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting. > this is a process that takes several years to finish. That’s the scale that we’re dealing with if we would like to perform some massive refactoring of the compiler internals There are other easier paths to improving the build times for common developer workflows.
jmyeet 1y ago
I'm a big fan of Rust but there are definitely warts that are going to be difficult to cure [1]. This is 5 years old now but I believe it's still largely relevant. It is a weird hill to die on for C/C++ devs though, given header files and templates creating massive compile-time issues that really can't be solved. Google is known for having infrastructure for compiling large projects. They use Blaze (open-sourced at Bazel) to define hermetic builds then use large systems to cache object graphs (for compilation units) and caching compiled objects because Google uses some significant monoliths that would take a significant amount of time to compile from scratch. I wonder what this kind of infrastructure can do for a large Rust project. [1]:https://www.pingcap.com/blog/rust-compilation-model-calamity/ https://www.pingcap.com/blog/rust-compilation-model-calamity...
- 1718627440 1y ago
  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++.
  - cozzyd 1y ago
    C++ compile times are why I often stick to C, which compiles nearly instantly.
    - teleforce 1y ago
      You can always upgrade to Dlang with modern features and conveniences that has comparable compilation time to C for the most parts (excluding CTFE).
daxfohl 1y ago
Maybe these features already exist, but I'd like a way to: 1) Type check without necessarily building the whole thing. 2) Run a unit test, only building the dependencies of that test. Do these exist or are they remotely feasible?
- lpapez 1y ago
  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!
- panstromek 1y ago
  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.
  - kibwen 1y ago
    cargo check absolutely helps as much as I'd hope for, and more. It's the basis of my entire workflow and it's like two seconds on my codebase.
  - Ar-Curunir 1y ago
    What? cargo check absolutely helps.
jtrueb 1y ago
A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, which further led to improving our CI infrastructure. Then I noticed that we wait quite a long time for our CI workflows, and started optimizing them. Then I started running the Rust Annual Survey, then our GSoC program, then improving our bots, then…
- agumonkey 1y ago
  Talk about proper `continuous improvement`
- c-cube 1y ago
  I'm worried this person is going to experience a Yak overflow, honestly.
  - mrec 1y ago
    Coincidentally, I discovered this glorious page literally five minutes ago: https://github.com/SerenityOS/yaksplained?tab=readme-ov-file#yakoverflow-the-programmers-favorite-website https://github.com/SerenityOS/yaksplained?tab=readme-ov-file...
  - culebron21 1y ago
    What a wonderful term. I love it!
- jamesmunns 1y ago
  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.
- deleted 1y ago
  [deleted]
jadbox 1y ago
Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memory issues (as much as say Java or C++).
- sfvisser 1y ago
  This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?
  - skrtskrt 1y ago
    For me the hangup is that async is Still Hard. Just a ridiculous amount of internal implementation details exposed in order to just write, like, an http middleware. We looked at proposing Rust as the second blessed language in addition to Go where I work, and the conclusion was basically... why? We have skilled Go engineers that can drop down to manual memory management and squeeze lots of extra performance out of it. And it's still dead simple when you don't need to do that or the task is suitable for a junior engineer. And channels are simply one of the best concurrency primitives out there, and baked into the language unlike Rust where everything is library making independent decisions. (to be fair I haven't tried Elixir/Erlang message passing, I understand people like that too).
  - akazantsev 1y ago
    For Go, it's a design decision. From the start, they strived to make compilation as fast as possible. https://en.wikipedia.org/wiki/Go_(programming_language)#Design https://en.wikipedia.org/wiki/Go_(programming_language)#Desi...
- bobbylarrybobby 1y ago
  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.
adrian17 1y ago
> On this benchmark, the compiler is almost twice as fast than it was three years ago. I think the cause of the public perception issue could be the variant of Wirth's law: the size of an average codebase (and its dependencies) might be growing faster than the compiler's improvements in compiling it?
- IshKebab 1y ago
  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.
littlestymaar 1y ago
In my experience working on medium-sized Rust projects (hundreds of thousands of LoCs, not millions), incremental compilation and mold pretty much solved the problem in practice. I still occasionally code on my 13 years old laptop when traveling and compilation time is fine even there (for cargo check and debug build, that is, I barely ever compile in release mode locally). What's painful is compiling from scratch, and particularly the fact that every other week I need to run cargo clean and do a full rebuild to get things working. IMHO this is a much bigger annoyance than raw compiler speed.
- sureglymop 1y ago
  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.
  - littlestymaar 1y ago
    Incremental compilation has been the default for a few years now. Mold isn't and won't be anytime soon but AFAIK there's a PR to use lld by default and that should happen sooner than later. It's not exactly as fast as mold but it will still be a linking speed boost for everyone by default.
kristoff_it 1y ago
> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it. This is an unfortunate hyperbole from the author. There's a lot of distance between DoD and "hand-rolled assembly" and thinking that it's fair to put them in the same bucket to justify the argument of maintainability is just going to hurt the Rust project's ability to make a better compiler for its users. You know what helps a lot making software maintainable? A Faster development loop. Zig has invested years into this and both users and the core team itself have started enjoying the fruits of that labor. https://ziglang.org/devlog/2025/#2025-06-08 https://ziglang.org/devlog/2025/#2025-06-08 Of course everybody is free to choose their own priorities, but I find the reasoning flawed and I think that it would ultimately be in the Rust project's best interest to prioritize compiler performance more.
- 90s_dev 1y ago
  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.
  - AndyKelley 1y ago
    For anyone who wants to form their own opinion about whether this style of programming is easier or harder than it would be in other languages: https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/tokenizer.zig https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/token...
    - Rusky 1y ago
      The tokenizer is not really a good demonstration of the differences between these styles. A more representative comparison would be the later stages that build, traverse, and manipulate tree and graph data structures.
Animats 1y ago
This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.
- afdbcreid 1y ago
  But how big are your big projects?
  - Animats 1y ago
    About 40,000 lines of my own code, plus a hundred or so crates from crates.io.
- johnfn 1y ago
  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.
  - kalaksi 1y ago
    Compile what language?
    - FridgeSeal 1y ago
      Probably js given they mentioned Vite; not exactly sure I’d call it “compiling” in nearly t he r same order of magnitude of complexity though…
  - shmerl 1y ago
    Consider how long it takes to compile the Linux kernel for example. So one minute is very good.
  - 1y ago
synthos 1y ago
Regarding AVX: could rust be compiled with different symbols that target different x64 instruction sets, then at runtime choose the symbol set that is the more performant for that architecture?
- kobzol 1y ago
  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).
johnfn 1y ago
> First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it. I'm probably being ungrateful here, but here goes anyway. Yes, Rust cares about performance of the compiler, but it would likely be more accurate to say that compiler performance is, like, 15th on the list of things they care about, and they'll happily trade off slower compile times for one of the other things. I find posts about Rust like this one, where they say "ah, of course we care about perf, look, we got the compile times on a somewhat nontrivial project to go from 1m15s to 1m09s" somewhat underwhelming - I think they miss the point. For me, I basically only care if compile times are virtually instantaneous. e.g. Vite scales to a million lines and can hot-swap my code changes in instantaneously. This is where the productivity benefits come in. Don't just trust me on it. Remember this post[1]? > "I feels like some people realize how much more polish could their games have if their compile times were 0.5s instead of 30s. Things like GUI are inherently tweak-y, and anyone but users of godot-rust are going to be at the mercy of restarting their game multiple times in order to make things look good. " [1]: https://loglog.games/blog/leaving-rust-gamedev/#compile-times-have-improved-but-not-with-proc-macros https://loglog.games/blog/leaving-rust-gamedev/#compile-time...
- kalaksi 1y ago
  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).
- kobzol 1y ago
  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.
- lenkite 1y ago
  I think Rust compiler team should just build a Rust interpreter for iterative, development mode. The compiler can only be sped up so far.
kunley 1y ago
The article is fine and has a lot of good points, but tries to avoid the main issue like a plague. So I will speak it here: The slowness comes mainly from LLVM.
- kobzol 1y ago
  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.
  - kunley 1y ago
    Fair reply, thank you.
- panstromek 1y ago
  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.
- yencabulator 1y ago
  The article briefly mentions Cranelift, though only as a link destination not by name. And that's a way to faster Rust builds, for sure! Currently only recommended for dev builds, not production.
juliangmp 1y ago
>[...] this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times Yeah pretty much. C++ is a lot worse when you consider the practical time spent vs compilation benchmarks. In most C++ projects I've seen/worked on, there were one or sometimes more code generators in the toolchain which slowed things down a lot. 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. When I work in Rust, the overall speed of the toolchain (and the language server) is an absolute blessing!
- carlmr 1y ago
  >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.
- feelamee 1y ago
  why do you run clang-tidy with compiler? Just use it interactively - with cland. These is much more useful to me
  - juliangmp 1y ago
    We do use clangd and it provides many checks, but I wanted to include clang-tidy in the CI. Though since me and my colleagues combine ff-only and ‘must build successfully before merging’, adding like 5 minutes to the CI is really annoying. Iirc the reason why clangd is so much faster than clang-tidy is that clangs omits certain checks and limits which code it analyzes.
bnolsen 1y ago
Compilation speed makes go nice. Zig should end up being king here depending on comptime use (ie: lack of operators can be overcome by using comptime to parse formulae strings for things like geometric algebra).
ruuda 1y ago
The Rust ecosystem is getting slower faster than the compiler is getting faster. Libraries grow to add features, they add dependencies. Individually the growth is not so bad, and justified by features or wider platform support. But they add up, and especially dependencies adding dependencies act as a multiplier. I started writing a post about this many years ago, but never finished it. I took a few slow-changing projects of mine that had a pinned Rust compiler, and then updated both the compiler and dependencies to the latest versions. Invariably, everything got slower to compile, even though the compiler update in isolation made things faster!
- simonask 1y ago
  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.
- eddd-ddde 1y ago
  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.
baalimago 1y ago
Seems to me that Rust has hit bedrock. If there's no tangible solution to this design flaw today, what will happen to it in 20 years? My expectation is that the amount of dependencies will increase, as will the complexity of the Rust ecosystem at large, which will make the compilation times even worse.
- zozbot234 1y ago
  It's OK; 20 years ought to be enough time to rewrite LLVM in Rust.
  - pjmlp 1y ago
    Being optimistic, given that LLVM rivals the Linux kernel on daily contributions.
- kobzol 1y ago
  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.
  - baalimago 1y ago
    >But we need more people to work on them. That's my point: 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. Especially considering all the gotchas, and continuous development of 'more fun' things (why work on open source if it's no fun?). That's why it's 'the bedrock'. To do something like that, Rust would need to be forked and later on rewritten with optimizations. But by then it wouldn't be "Rust" anymore, it would be a sibling language with rusty syntax. Rust++, perhaps.
    - diggan 1y ago
      > 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 has always been like this according to you? > why work on open source if it's no fun It's always fun to someone out there, I'm sure :) There are loads of thankless tasks that seemingly get done even without having a sexy name like "AI for X". With a language as large as Rust, I'm sure there might even be two whole people who are salivating at the ideas of speeding up the current compiler.
baalimago 1y ago
Why haven't Rust been forked by some bigger company, who have the time and resources to specialize it into something which fits better into a professional market? Yes I'm saying low compilation time -> high development RTT is a requirement for the professional market.
- WJW 1y ago
  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.
- bob1029 1y ago
  > 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.
kjuulh 1y ago
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 much, only when paired with building for multiple targets at once. I.e. Leptos where a wasm and native build is run. Incremental builds do however, eat up a lot of space, a comical amount even. I had a 28GB target/ folder yesterday from working a few hours on a leptos app. One recommendation is to definitely upgrade your CI workers, Rust definitely benefits from larger workers than the default GitHub actions runners as an example. Compilling a fairly simple app, though including DuckDB which needs to be compiled, took 28 minutes on default runners. but on a 32x machine, we're down to around 3 minutes. Which is fast enough that it doesn't disrupt our feedback loop.
- crohr 1y ago
  What kind of CI runners do you use then? Do you self-host?
  - kjuulh 1y ago
    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.
lrvick 1y ago
If anyone wants to feel better about compile times for their rust programs, try full source bootstrapping the rust compiler itself. Took about 2 days on 64 cores until very recently (thanks to mrustc 0.74). Now only 7 hours!
superkuh 1y ago
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.
ModernMech 1y ago
The biggest thing that's happened in recent time to improve Rust compiler performance was the introduction the Apple M-series chips. On my x86 machine, it'll take maybe 10 minutes for a fresh build of my project, but on my Apple machine that's down to less than a minute, even on the lower end Mac Mini. For incremental builds it only takes a few seconds. I'm fine with this amount of compilation time for what it buys me, and I don't feel it slows me down any because (and I know this sounds like cope) it gives me a minute to breathe and collect my thoughts. Sometimes I find that debugging a problem while actively coding in an interactive REPL is different from debugging offline. I'm not sure why but the way I would explain it is when you're debugging in an interactive REPL you're always get fast incremental result, but you may be going down an unproductive rabbit hole and spinning your tires. When I hit that compile button, I'm able to take a step back and maybe see the problem from another angle. Still, I prefer a short development loop, but I do think you lose something from it.

287 points by mellosouls 1y ago

dboreham 1y ago

I'd vote for filesystem space utilization to be worked on before performance.

kzrdude 1y ago
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" :)
- estebank 1y ago
  There are multiple avenues to improve both first and incremental compiles. They "just" require large architectural changes that may yield marginal improvements, so it's hard to get those projects off the ground. But after the last project all-hands I do expect at least one of these to be pursued, of not more. There are cases where cargo recompiles crates "unnecessarily", cargo+rustc could invert the compilation pyramid to start at the root and then only compile reachable items (similar effect to LTO, but can produce a binary if an item with a compile error isn't evaluated, improving clean compiles), having better communication with linkers and having access to incremental linking would be a boon for incremental compiles, etc.
stevedonovan 1y ago
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)
- vlovich123 1y ago
  Correct builds != never running garbage cleanup. I would settle for it evicting older variants of a build (I also dislike the random hash that’s impossible to determine what specifically is different between two hashes / which one is newer).
  - mbrubeck 1y ago
    Automatic garbage collection of old build artifacts* is coming in Rust 1.88 (currently on the beta channel, will become the new stable release in two weeks): https://github.com/rust-lang/cargo/issues/12633 https://github.com/rust-lang/cargo/issues/12633 *EDIT: For now this only deletes old cached downloads, not build artifacts. Thanks epage for the correction below.
    - vlovich123 1y ago
      That’s as an additional flag and not the default?
      - mbrubeck 1y ago
        In versions earlier than 1.88, garbage collection required the unstable -Zgc flag (and a nightly toolchain). But in 1.88 and later, automatic garbage collection is enabled by default.
    - epage 1y ago
      That is not for build artifacts but global caches like for `.crate` files but its a stepping stone.
      - mbrubeck 1y ago
        Oops, thanks for the correction.
- epage 1y ago
  A little of both. Incremental compilation cache is likely the single largest item in the target directory but it gets cleaned up on each invocation so it doesn't scale in size with time. I believe the next release will have a cache GC but only for global caches (e.g. `.crate` files). I'd like us to at least cleanup the layout of the target directory so its easier to track stuff before GCing it. Work is underway for this. A cheap GC we could add earlier is for artifacts specific to older cargo versions.
dralley 1y ago
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.
scripturial 1y ago
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.
ivanjermakov 1y ago
This is one of the only reasons I disliked Haskell. GHC and lib files can easily take over 2GB of storage.
MeetingsBrowser 1y ago
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.
- estebank 1y ago
  > Why not both? For better and worse, the Rust project is a "show-up-ocracy": the work that gets done is the one that volunteers (or paid employees from a company donating their time to the project) spend time doing. It's hard in open source projects to tell people "this is important and you must work on it", but rather you have to convince people that it is important and have to hope they will have the time, inclination and skill to work on it. FWIW, people were working on the cargo cache GC feature years ago[1], but I am not aware of what the current state of that is. I wouldn't be surprised if it wasn't turned on because there are unresolved questions. 1: https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning/ https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning/
  - Ygg2 1y ago
    > For better and worse, the Rust project is a "show-up-ocracy" So it's an OSS project?
    - windward 1y ago
      Linux and GCC are OSS projects but CPU companies pour work into their development because it's a strict requirement of being able to sell their products.
      - pjmlp 1y ago
        Just like Amazon, Microsoft and Google nowadays pour work into Rust.
preciousoo 1y ago
What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?
- jakkos 1y ago
  You can: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
  - preciousoo 1y ago
    Oh this is amazing, looks simple to set up too. Thanks!
    - kstrauser 1y ago
      It's a game-changer, especially on my slower machines like Raspberry Pis. They can use every advantage they can get.
- epage 1y ago
  That work is being tracked in https://github.com/rust-lang/cargo/issues/5931 https://github.com/rust-lang/cargo/issues/5931 Someone has taken up the work on this though there are some foundational steps first. 1. We need to delineate intermediate and final build artifacts so people have a clearer understanding in `target/` what has stability guarantees (implemented, awaiting stabilization). 2. We then need to re-organize the target directory from being organized by file type to being organized by crate instance. 3. We need to re-do the file locking for `target/` so when we share things, one cargo process won't lock out your entire system 4. We can then start exploring moving intermediate artifacts into a central location. There are some caveats to this initial implementation - To avoid cache poisoning, this will only items with immutable source that and an idempotent build, leaving out your local source and stuff that depends on build scripts and proc-macros. There is work to reduce the reliance on build scripts and proc-macros. We may also need a "trust me, this is idempotent" flag for some remaining cases. - A new instance of a crate will be created in the cache if any dependency changes versions, reducing reuse. This becomes worse when foundation crates release frequently and when adding or updating a specific dependency, Cargo prefers to keep all existing versions, creating a very unpredictable dependency tree. Support for remote caches, especially if you can use your project's CI as a cache source, would help a lot with this.
jakkos 1y ago
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 :'(
kibwen 1y ago
The previous post on the OP's blog is about exactly this: https://kobzol.github.io/rust/rustc/2025/06/02/reduce-cargo-target-dir-size-with-z-no-embed-metadata.html https://kobzol.github.io/rust/rustc/2025/06/02/reduce-cargo-...

vlovich123 1y ago

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. I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.

dhruvrajvanshi 1y ago
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.
- pjmlp 1y ago
  That approach is what you get in Common Lisp, Eiffel, Oberon language family, Java, .NET, Julia (getting there), Haskell, OCaml, C++ (with something like ROOT or C++/CLI). So if enough people care for Rust, it is also possible.
zozbot234 1y ago
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.
bbatha 1y ago
> 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 https://github.com/rust-lang/rustc_codegen_cranelift

jplusequalt 1y ago

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

logicchains 1y ago
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.
- MeetingsBrowser 1y ago
  There are things you can do for Rust if it really is a deal breaker. Dioxus has a hot reload system. Some rust game engines have done similar things.
  - jplusequalt 1y ago
    When in doubt, manually patch your dll's
- kibwen 1y ago
  You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize. To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
  - pjmlp 1y ago
    You certainly cannot distribute binary libraries, including pre-expanded templates for common use cases. Which is always my standard approach to fast build times in C++ projects.
0cf8612b2e1e 1y ago

panstromek 1y ago

The original title is: Why doesn't Rust care more about compiler performance?

mellosouls 1y ago
(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.

norir 1y ago

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, so it seems probable that compilation will always be slow.

awestroke 1y ago
[flagged]
- MeetingsBrowser 1y ago
  The original comment is mostly inline with the article. All the easy local optimizations have been done. Even mostly straightforward compiler wide changes take a team of people multiple years to land. Re-architecting the rust compiler to be faster is probably not going to happen.
  - kibwen 1y ago
    > Re-architecting the rust compiler to be faster is probably not going to happen. This is a statement without the weight of evidence. The Rust compiler has been continually rearchitected since 1.0, and has doubled its effective performance multiple times since then.
    - MeetingsBrowser 1y ago
      I'm going off of what is in the article. > The second way forward is performing massive changes and/or refactorings to the implementation of the compiler. However, that is of course challenging, for a number of reasons. > if you change one thing at the “bottom” layer of the compiler, you will then have to go through hundreds of places and fix them up, and also potentially fix many test cases, which can be very time-consuming > You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail. Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting. > this is a process that takes several years to finish. That’s the scale that we’re dealing with if we would like to perform some massive refactoring of the compiler internals There are other easier paths to improving the build times for common developer workflows.

jmyeet 1y ago

I'm a big fan of Rust but there are definitely warts that are going to be difficult to cure [1]. This is 5 years old now but I believe it's still largely relevant. It is a weird hill to die on for C/C++ devs though, given header files and templates creating massive compile-time issues that really can't be solved. Google is known for having infrastructure for compiling large projects. They use Blaze (open-sourced at Bazel) to define hermetic builds then use large systems to cache object graphs (for compilation units) and caching compiled objects because Google uses some significant monoliths that would take a significant amount of time to compile from scratch. I wonder what this kind of infrastructure can do for a large Rust project. [1]:https://www.pingcap.com/blog/rust-compilation-model-calamity/ https://www.pingcap.com/blog/rust-compilation-model-calamity...

1718627440 1y ago
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++.
- cozzyd 1y ago
  C++ compile times are why I often stick to C, which compiles nearly instantly.
  - teleforce 1y ago
    You can always upgrade to Dlang with modern features and conveniences that has comparable compilation time to C for the most parts (excluding CTFE).

daxfohl 1y ago

Maybe these features already exist, but I'd like a way to: 1) Type check without necessarily building the whole thing. 2) Run a unit test, only building the dependencies of that test. Do these exist or are they remotely feasible?

lpapez 1y ago
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!
panstromek 1y ago
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.
- kibwen 1y ago
  cargo check absolutely helps as much as I'd hope for, and more. It's the basis of my entire workflow and it's like two seconds on my codebase.
- Ar-Curunir 1y ago
  What? cargo check absolutely helps.

jtrueb 1y ago

A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, which further led to improving our CI infrastructure. Then I noticed that we wait quite a long time for our CI workflows, and started optimizing them. Then I started running the Rust Annual Survey, then our GSoC program, then improving our bots, then…

agumonkey 1y ago
Talk about proper `continuous improvement`
c-cube 1y ago
I'm worried this person is going to experience a Yak overflow, honestly.
- mrec 1y ago
  Coincidentally, I discovered this glorious page literally five minutes ago: https://github.com/SerenityOS/yaksplained?tab=readme-ov-file#yakoverflow-the-programmers-favorite-website https://github.com/SerenityOS/yaksplained?tab=readme-ov-file...
- culebron21 1y ago
  What a wonderful term. I love it!
jamesmunns 1y ago
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.
deleted 1y ago
[deleted]

jadbox 1y ago

Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memory issues (as much as say Java or C++).

sfvisser 1y ago
This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?
- skrtskrt 1y ago
  For me the hangup is that async is Still Hard. Just a ridiculous amount of internal implementation details exposed in order to just write, like, an http middleware. We looked at proposing Rust as the second blessed language in addition to Go where I work, and the conclusion was basically... why? We have skilled Go engineers that can drop down to manual memory management and squeeze lots of extra performance out of it. And it's still dead simple when you don't need to do that or the task is suitable for a junior engineer. And channels are simply one of the best concurrency primitives out there, and baked into the language unlike Rust where everything is library making independent decisions. (to be fair I haven't tried Elixir/Erlang message passing, I understand people like that too).
- akazantsev 1y ago
  For Go, it's a design decision. From the start, they strived to make compilation as fast as possible. https://en.wikipedia.org/wiki/Go_(programming_language)#Design https://en.wikipedia.org/wiki/Go_(programming_language)#Desi...
bobbylarrybobby 1y ago
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.

adrian17 1y ago

> On this benchmark, the compiler is almost twice as fast than it was three years ago. I think the cause of the public perception issue could be the variant of Wirth's law: the size of an average codebase (and its dependencies) might be growing faster than the compiler's improvements in compiling it?

IshKebab 1y ago
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.

littlestymaar 1y ago

In my experience working on medium-sized Rust projects (hundreds of thousands of LoCs, not millions), incremental compilation and mold pretty much solved the problem in practice. I still occasionally code on my 13 years old laptop when traveling and compilation time is fine even there (for cargo check and debug build, that is, I barely ever compile in release mode locally). What's painful is compiling from scratch, and particularly the fact that every other week I need to run cargo clean and do a full rebuild to get things working. IMHO this is a much bigger annoyance than raw compiler speed.

sureglymop 1y ago
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.
- littlestymaar 1y ago
  Incremental compilation has been the default for a few years now. Mold isn't and won't be anytime soon but AFAIK there's a PR to use lld by default and that should happen sooner than later. It's not exactly as fast as mold but it will still be a linking speed boost for everyone by default.

kristoff_it 1y ago

> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it. This is an unfortunate hyperbole from the author. There's a lot of distance between DoD and "hand-rolled assembly" and thinking that it's fair to put them in the same bucket to justify the argument of maintainability is just going to hurt the Rust project's ability to make a better compiler for its users. You know what helps a lot making software maintainable? A Faster development loop. Zig has invested years into this and both users and the core team itself have started enjoying the fruits of that labor. https://ziglang.org/devlog/2025/#2025-06-08 https://ziglang.org/devlog/2025/#2025-06-08 Of course everybody is free to choose their own priorities, but I find the reasoning flawed and I think that it would ultimately be in the Rust project's best interest to prioritize compiler performance more.

90s_dev 1y ago
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.
- AndyKelley 1y ago
  For anyone who wants to form their own opinion about whether this style of programming is easier or harder than it would be in other languages: https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/tokenizer.zig https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/token...
  - Rusky 1y ago
    The tokenizer is not really a good demonstration of the differences between these styles. A more representative comparison would be the later stages that build, traverse, and manipulate tree and graph data structures.

Animats 1y ago

This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.

afdbcreid 1y ago
But how big are your big projects?
- Animats 1y ago
  About 40,000 lines of my own code, plus a hundred or so crates from crates.io.
johnfn 1y ago
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.
- kalaksi 1y ago
  Compile what language?
  - FridgeSeal 1y ago
    Probably js given they mentioned Vite; not exactly sure I’d call it “compiling” in nearly t he r same order of magnitude of complexity though…
- shmerl 1y ago
  Consider how long it takes to compile the Linux kernel for example. So one minute is very good.
- 1y ago

synthos 1y ago

Regarding AVX: could rust be compiled with different symbols that target different x64 instruction sets, then at runtime choose the symbol set that is the more performant for that architecture?

kobzol 1y ago
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).

johnfn 1y ago

> First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it. I'm probably being ungrateful here, but here goes anyway. Yes, Rust cares about performance of the compiler, but it would likely be more accurate to say that compiler performance is, like, 15th on the list of things they care about, and they'll happily trade off slower compile times for one of the other things. I find posts about Rust like this one, where they say "ah, of course we care about perf, look, we got the compile times on a somewhat nontrivial project to go from 1m15s to 1m09s" somewhat underwhelming - I think they miss the point. For me, I basically only care if compile times are virtually instantaneous. e.g. Vite scales to a million lines and can hot-swap my code changes in instantaneously. This is where the productivity benefits come in. Don't just trust me on it. Remember this post[1]? > "I feels like some people realize how much more polish could their games have if their compile times were 0.5s instead of 30s. Things like GUI are inherently tweak-y, and anyone but users of godot-rust are going to be at the mercy of restarting their game multiple times in order to make things look good. " [1]: https://loglog.games/blog/leaving-rust-gamedev/#compile-times-have-improved-but-not-with-proc-macros https://loglog.games/blog/leaving-rust-gamedev/#compile-time...

kalaksi 1y ago
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).
kobzol 1y ago
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.
lenkite 1y ago
I think Rust compiler team should just build a Rust interpreter for iterative, development mode. The compiler can only be sped up so far.

kunley 1y ago

The article is fine and has a lot of good points, but tries to avoid the main issue like a plague. So I will speak it here: The slowness comes mainly from LLVM.

kobzol 1y ago
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.
- kunley 1y ago
  Fair reply, thank you.
panstromek 1y ago
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.
yencabulator 1y ago
The article briefly mentions Cranelift, though only as a link destination not by name. And that's a way to faster Rust builds, for sure! Currently only recommended for dev builds, not production.

juliangmp 1y ago

>[...] this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times Yeah pretty much. C++ is a lot worse when you consider the practical time spent vs compilation benchmarks. In most C++ projects I've seen/worked on, there were one or sometimes more code generators in the toolchain which slowed things down a lot. 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. When I work in Rust, the overall speed of the toolchain (and the language server) is an absolute blessing!

carlmr 1y ago
>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.
feelamee 1y ago
why do you run clang-tidy with compiler? Just use it interactively - with cland. These is much more useful to me
- juliangmp 1y ago
  We do use clangd and it provides many checks, but I wanted to include clang-tidy in the CI. Though since me and my colleagues combine ff-only and ‘must build successfully before merging’, adding like 5 minutes to the CI is really annoying. Iirc the reason why clangd is so much faster than clang-tidy is that clangs omits certain checks and limits which code it analyzes.

bnolsen 1y ago

Compilation speed makes go nice. Zig should end up being king here depending on comptime use (ie: lack of operators can be overcome by using comptime to parse formulae strings for things like geometric algebra).

ruuda 1y ago

The Rust ecosystem is getting slower faster than the compiler is getting faster. Libraries grow to add features, they add dependencies. Individually the growth is not so bad, and justified by features or wider platform support. But they add up, and especially dependencies adding dependencies act as a multiplier. I started writing a post about this many years ago, but never finished it. I took a few slow-changing projects of mine that had a pinned Rust compiler, and then updated both the compiler and dependencies to the latest versions. Invariably, everything got slower to compile, even though the compiler update in isolation made things faster!

simonask 1y ago
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.
eddd-ddde 1y ago
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.

baalimago 1y ago

Seems to me that Rust has hit bedrock. If there's no tangible solution to this design flaw today, what will happen to it in 20 years? My expectation is that the amount of dependencies will increase, as will the complexity of the Rust ecosystem at large, which will make the compilation times even worse.

zozbot234 1y ago
It's OK; 20 years ought to be enough time to rewrite LLVM in Rust.
- pjmlp 1y ago
  Being optimistic, given that LLVM rivals the Linux kernel on daily contributions.
kobzol 1y ago
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.
- baalimago 1y ago
  >But we need more people to work on them. That's my point: 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. Especially considering all the gotchas, and continuous development of 'more fun' things (why work on open source if it's no fun?). That's why it's 'the bedrock'. To do something like that, Rust would need to be forked and later on rewritten with optimizations. But by then it wouldn't be "Rust" anymore, it would be a sibling language with rusty syntax. Rust++, perhaps.
  - diggan 1y ago
    > 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 has always been like this according to you? > why work on open source if it's no fun It's always fun to someone out there, I'm sure :) There are loads of thankless tasks that seemingly get done even without having a sexy name like "AI for X". With a language as large as Rust, I'm sure there might even be two whole people who are salivating at the ideas of speeding up the current compiler.

baalimago 1y ago

Why haven't Rust been forked by some bigger company, who have the time and resources to specialize it into something which fits better into a professional market? Yes I'm saying low compilation time -> high development RTT is a requirement for the professional market.

WJW 1y ago
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.
bob1029 1y ago
> 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.

kjuulh 1y ago

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 much, only when paired with building for multiple targets at once. I.e. Leptos where a wasm and native build is run. Incremental builds do however, eat up a lot of space, a comical amount even. I had a 28GB target/ folder yesterday from working a few hours on a leptos app. One recommendation is to definitely upgrade your CI workers, Rust definitely benefits from larger workers than the default GitHub actions runners as an example. Compilling a fairly simple app, though including DuckDB which needs to be compiled, took 28 minutes on default runners. but on a 32x machine, we're down to around 3 minutes. Which is fast enough that it doesn't disrupt our feedback loop.

crohr 1y ago
What kind of CI runners do you use then? Do you self-host?
- kjuulh 1y ago
  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.

lrvick 1y ago

If anyone wants to feel better about compile times for their rust programs, try full source bootstrapping the rust compiler itself. Took about 2 days on 64 cores until very recently (thanks to mrustc 0.74). Now only 7 hours!

superkuh 1y ago

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.

ModernMech 1y ago

The biggest thing that's happened in recent time to improve Rust compiler performance was the introduction the Apple M-series chips. On my x86 machine, it'll take maybe 10 minutes for a fresh build of my project, but on my Apple machine that's down to less than a minute, even on the lower end Mac Mini. For incremental builds it only takes a few seconds. I'm fine with this amount of compilation time for what it buys me, and I don't feel it slows me down any because (and I know this sounds like cope) it gives me a minute to breathe and collect my thoughts. Sometimes I find that debugging a problem while actively coding in an interactive REPL is different from debugging offline. I'm not sure why but the way I would explain it is when you're debugging in an interactive REPL you're always get fast incremental result, but you may be going down an unproductive rabbit hole and spinning your tires. When I hit that compile button, I'm able to take a step back and maybe see the problem from another angle. Still, I prefer a short development loop, but I do think you lose something from it.