Faster compile and smaller build-dir can be at odds with each other.

That said, this release includes some incremental improvements as well as the unused-dependency lint to help reduce wasted work within the ecosystem.

Some changes that have been or are about to be merged for upcoming releases

- We will be reducing the debug info generated for the `dev` profile which reduces build-dir size and speeds up builds. We've split off a `debug` profile for when that is needed.

- Cargo will be deleting the directory rustc writes before each invocation, avoiding the leaking of debug files when split-debug is enabled (default on Mac)

- rlibs for workspace members will no longer be copied from build-dir to target-dir which takes up extra space on systems without hardlinking or where we skip it (like Mac)

- redundant information in rlibs and rmeta's is going to be de-duplicated

Examples of further out changes

- This release includes the foundational work to add a build-dir GC

- Cross-workspace de-duplicating of build-dirs

- Cross-workspace build-dir cache

- Early cut off

Compiler speed is continually being worked on https://nnethercote.github.io/2026/11/04/how-to-speed-up-the...

And the large target directories is also being worked on as well.

Yes this is why I switched to Go for backend, much faster compiling and performance isn't an issue for the application yes using 100GB+ is just bad tooling.

try disabling at least some debug-info for your dependencies.

use cargo's --timings option to identify the slow crates, then use measureme to figure where rustc is spending time.

try fiddling with detached debug-info, dwp files can be smaller than their constituent dwo files.

ensure really small "template wrappers" are inlined.

lower the number of compilation-units you use.

For incremental builds I have found it can _sometimes_ be effective to split out larger dependencies into a dynlib. You create a dylib crate that re-exports said dependencies and your executable depends on that. Ofc things like generics from the offending libraries will still end up in your executables; Though I think there is a way to mitigate this a little.

This mostly helps with link-time, and saving space if you have a bunch of executables (using the argv[0] trick will help more, though).

Any faster vs what baseline? They’ve constantly made improvements and Rust today is pretty darn quick, especially for incremental. There’s work to parallelize the front end which will help a little bit and you can always use the cranelift backend for debugging which is substantially faster than LLVM.

They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.

You might be interested in this: https://news.ycombinator.com/item?id=50458849 - I didn't try it yet, though.

Is the compiler any faster now?

If your codebase is not some small project, its excruciating slow. Even if you try different linkers, and other compilers, nothing really make incremental compiles eat so much of your system. Even more so if you have multiple AI agents doing security and other checks.

Switched to Go for several months, and the difference was very noticeable. Until you started to get there also 50k+ files that are interlinked. And let us not talk about Go and Rust their issues with insane amount of debug/cache buildup.

Imaging if you have 4 to 6 agents running that, with each seeing the cache grow from 20, 30, 40 ... To the point that a 100/1000GB SSD grows to 800, 900GB usage. Often in barely a day.

Seen my NVME drive its lifespan drop from 98% to 91% in barely a few month time. I dread looking at it again lol

What was the solution? Going back to C ... Despite right now working on a 800k lines project, it compiles way faster the Go, and well, Rust will have pegged all 16 cores for a minute, for EACH agent trying to recompile on a small change.

Memory safety? Instead of checking at compile time, and wasting my time, this has simply been moved to AI agents checking, making tools, checking, at night. So it does not disturb my own work.

Its ironic, how both modern projects, end up being worse off. Best of all, the C project is way faster then the same project in Go and Rust. Yea, it was "fun" having AI transcompile them twice but the difference on actual large codebase, and not some micro benchmarks is not a joke. To the point that now all my projects have gone back to C...

And yea, i expect some fast downvotes by our Rust friends because saying something negative about Rust always gets people downvoted here. No offence but Rust being linked to LLM and the whole checker was a benefit before AI came around. But now you can offload a lot of safety checks to the backend/offhours, instead of paying for it with every compile.

There's really a paradox here. Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...

On macOS there is a known bug where some temp files are always created anew, not reused, which slows down compilation and wastes more space than other platforms.

All the big AI companies use Rust so this is probably something they should focus on improving.

Well, the AI that slops out Rust code won't mind having to wait!

I don't understand why people complain about this non-stop. If compilation time is such an issue use a different language. I can't say I've been bottlenecked by compilation in a very long time.