alt Hacker NewsHaving spent ~3 weeks of evenings and weekends on this, I was a bit burned out to keep trying to optimize especially because all of this code is just a dead end anyway...
The fix seemed to be to split up Bun's Zig module into ~100 pieces just like they've done on Rust but how representative that would have been on anything Bun might of shipped is very much in question!
Replies
The next questions in my head are:
A) Is there any performance penalty on the compiled result due to being optimized in separate pieces
B) If not, why isn't the optimizer smart enough to split them up internally and optimize in parallel?
Your post went into way more depth than I was expecting when I first opened up it up. You clearly spent a lot of time on it and I appreciated reading the tale so thank you. Given all the drama around AK / Bun, it just would have been so funny to see someone not involved in the project solve one of the main motivations for the move to rust.
I believe there is a fork of bun from 1.3 that a different community is maintaining. I wonder if they’ve been able to get the compile times down by modularizing the build?
Can you force a non-parallel build of those rust crates to make the comparison fairer?
The issue with splitting up Bun's Zig module is that Rust is designed for multiple crates compiling separate objects and linking them together in the end, but for Zig you would need to manually export and import C abi functions and you can't make use of language features like slices, generics, non-extern structs, and others anymore. In Zig, every module is compiled in the same compilation unit. Even the standard library is compiled in the same unit as your app.