I made a build visualizer to understand Bun's compile times

anaqin•about 2 hours ago

Good write up! I was hoping it was going to conclude with the author getting buns zig build way faster than Rusts but a good deep dive nevertheless

lalitmaganti•about 2 hours ago

Having 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!

rahkiin•about 2 hours ago

Can you force a non-parallel build of those rust crates to make the comparison fairer?

Retro_Dev•about 1 hour ago

this! - the reason Zig defaults to one semantic analysis thread is due to current (to be improved) limitations; some ideas for Zig also will require one compilation unit - the restricted function pointers proposal being a good example: https://github.com/ziglang/zig/issues/23367

The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.

anaqin•about 1 hour ago

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?

t43562•about 2 hours ago

It's like Electric Insight, which was a fantastic if proprietary tool.

There's an enormous amount of analysis you can do with tools like this from estimating how much faster the build would be with more cores (i.e. is it worth adding more) to things like a diff of one build against another: why is one build bad and the other good - what tasks had different parameters or weren't in both builds?

flimflamm•about 2 hours ago

It would be interesting to see what would be good input for LLMs to do the optimizations / trials on that automatically. Is the visual representation best or something else?

lalitmaganti•about 2 hours ago

It's actually trivially easy to add a "automated report" feature to buildprof due to its architecture (just a few SQL queries on top of Perfetto's trace processor). And I'm sure AI could hill climb the build time based on this.

But I still think the visual view is invaluable for human understanding and for the "why is this even happening" problems which I think AI is still bad at seeing.

Conlectus•about 2 hours ago

This is just how hacker news is now, huh?

“I did this cool useful thing”

“Great! Please describe how I can get a machine to replace you.”

I made a build visualizer to understand Bun's compile times

⚡ Community Insights

Discussion (9 Comments)Read Original on HackerNews