Comment by embedding-shape
3 days ago
Sounds lovely, give it a try on the codex-rs which seems to be getting close to using 2K crates in their repository any time now. Takes like 30 minutes to compile on a my beefy machine and it's a goddamn TUI, not sure what's going on, and not too interested in diving into that beast either.
I build it with `cargo build -p codex-cli --bin codex` in under 4 minutes on my old M1 MacBook Pro with 64GB memory compiling more than 1250 crates.
Sure, that compiles in a few minutes for me too, give it a try with a release build and compiling the full workspace though, since the point here is to stress the compiler :)
It’s insane. 45 minutes to build debug from scratch. Linking is super slow even in debug and that’s without LTO.
Incremental compilation is not cleaned up. Older deps pile up and don’t get cleaned.
Run out of disk space? Oh it’s just the 200+ GB codex-rs target folder.
Forget about doing worktrees.
Rust has a lot of work to do.
If there's a project that takes 45 minutes to produce a debug build from scratch, that's not a Rust problem, that's a them problem.
Let's compare. I just checked out ripgrep and built it and all its dependencies from scratch. Total time to produce a debug build: 6.92 seconds. This is inside a 16GB VM on a random Linux laptop (on battery); no beefy hardware here.
Let's try something beefier. I just checked out uutils (an implementation of coreutils) and built it from scratch. Total time to produce debug builds, for eighty binaries and all their dependencies: 30.26 seconds.
Let's try something beefier. I just checked out Servo, an entire browser engine, and built it and all its dependencies from scratch. Total time to build and link its one-thousand one-hundred and ten compilation units (along with its infamously huge and serial servo-script bottleneck) into a binary: 4 minutes and 38 seconds.
If Codex takes 45 minutes to build from scratch, that's an indictment of OpenAI and their development processes.
Arguably it is a rust problem. Rust can be improved to reduce the need to do as much manual maintenance of crates dynamics to allow for faster build times. The "you're holding it wrong" answer is not a good perspective to apply and I am surprised to see a prominent member of the rust community using it.
1 reply →
A full debug build of the DMD D compiler takes 3 seconds on my Mac Mini.
> Incremental compilation is not cleaned up. Older deps pile up and don’t get cleaned.
This is one of those problems that’s both huge/important, and probably impossible to solve. It bites me all the time, I have a measly 1TB nvme disk and I basically have to wipe my target directory and docker build cache (I have a shared cargo cache volume across builds) every other day. I’ve had this workstation for 2.5 years now and I’m honestly worried about nand endurance coming to bite me soon.
How would one even solve this? When do you know a cache entry won’t be used any more? Trace back provenance of artifacts to their sources, and if the mtimes have been bumped just delete the artifacts? It’s not like resetting source files to older mtimes is a good idea anyway…
I disagree it’s impossible to solve. Huge C++ projects don’t have continuously growing build directories and can still compile incrementally correctly.
1 reply →
I've abandoned zig for rust. I expected to be annoyed by rust build times, but so far it's been quite good for my needs. To the contrary it has not been any impediment even when prost etc all drag in many deps from a cold build.
The zig compiler apart from a couple of cross build or linker issues is darn good. Switch to rust is a function of library support, private struct fields. Rust itself is better organized and far better documented compared to zig.
However, rust has got to get their allocators for container support straightened out soon. I do SAAS for fintech and low level packet transports. Both benefit greatly with allocators custom designed for job at hand.
45 mins strikes me as something else is amiss ...
> However, rust has got to get their allocators for container support straightened out soon
Good news: https://github.com/rust-lang/rust/pull/156882
The allocator API has been stabilized, to be released in Rust 1.100 in November. (Though only Vec and Box will support custom allocators immediately; the rest of the standard library collections are coming later.)
> Linking is super slow even in debug
Linking is normally slower in debug btw (because of the debug info)
Use the split-debuginfo setting in your Cargo.toml to have the DWARF bypass the linker (on Linux, YMMV on other platforms).
This is why I like Zig and Go. :)
Worktrees can work with a shared build cache.
And this specifically work with Rust and target/ directory? Please do share what you've validated to actually work here.
It has 1.8 million lines of rust. That compilation time seems close to what I'd expect at that size. If you want something faster you should focus on distributed build caching rather than speeding up the compiler. Also note that crates are effectively equivalent to a single file in c++ as it's the compilation unit. This is similar to compiling 2k files that average 1k loc each in c++. I'm sure it's much worse when you account for macro expansion and generics.
As they say, it's a damn TUI for a chat bot. 1.8 MLoC is like 50x what you'd expect from something like that. If you want to speed up compilation, reducing that absolutely insane bloat would be a good start
> If you want something faster you should focus on distributed build caching rather than speeding up the compiler
... But the whole point is that that project is big, unwieldy and has lots of crates, both their own and 3rd party. Slapping a cache in front of it kind of defeats the purpose here, to see how parent's thing would speed things up for really large projects.
This thing is a monster, blows out the disk space on a Claude code web session. Will run it on my test server later and let you know.
Now I want to test it too! Need any testers with Threadripper systems to really see what it can do? ;) Email in profile
I will email you when I have something up for sure! First cargo check has it at about 28% reduced on codex rs, from 383 seconds down to 277 seconds on a 16 core machine. No -Zthreads yet though, and that typically has a similar effect and reduces the speed up the early meta data gives.
3 replies →