Hacker News Reader

Comment by Signez | Hacker News Reader

Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town.

How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?

View on HN

This is a fantastic talk on some of the optimizations that Zig makes easy to implement: https://vimeo.com/649009599

Bun is written in Zig, but it takes the same approach that esbuild took to make things fast: a linear, synchronous pipeline fitting as much as possible in the CPU cache with as little allocation and other overhead as possible. Zig has more knobs to turn than Go.

Bun goes one step further and does a great job of offloading work to the kernel when possible, too (i.e. the large file I/O improvement with the Linux kernel)

Zig is cool, but Bun heavily relies on JSC which is written in C++

But bundling doesn't

JSC is a multi-tier JIT with the last stage ultimately being LLVM, so if you want to be pedantic, Bun relies on LLVM’s optimizer which is written in C++.

The transpiling itself is written in Zig, which is the part that has the performance improvement. If Bun relied on JavaScript and JSC for the heavy lifting, it would be no faster than the other JS bundlers.

edit: no longer LLVM: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...

I really hate to talk about software based on the language they're written in and I don't mean to imply one language is better or worse but the upper bound of performance on Zig is likely easier to reach and likely higher than the upper bound of performance in Go. Though it may depend on the workload. (esbuild being written in Go.)

Reply on news.ycombinator.com