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
“Relink, don't rebuild” #790
And the large target directories is also being worked on as well.
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).
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)
Is Python a fast language because it barely takes any time to compile the code? No obviously not.
> If you could reinvent/change any aspect of Rust, what would you do alternatively?
> A lot happened because we wanted to ship a useful thing with only so much time in the day, so some things were less deliberate than others. There’s an alternate version of Rust with significantly faster compiler times, because while we cared about compile times when designing we always prioritized other values more. We never asked ourselves how this feature or implementation impacted compiler analysis time and there are several spots where something slightly different would have much faster compiler times, which people do care about. But had we spent time on that, we would have neglected other things and not been any more successful.
[1]: https://alexalejandre.com/interviews/interview-with-steve-kl...
This is important, because most often during development you want fast compilation times more than you want fast code.
But some of it is implementation problems.
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.
But that said I do agree it is pretty fast these days. Significantly faster than C++ and people have tolerated that for decades.