May 15, 2026
Benchmarking Bun's Rust Rewrite Against Bun v1.3.14 on an M1 MacBook Air
I wanted a narrow, auditable answer to one question: on my Apple M1 MacBook Air, how does Bun's exact Rust rewrite PR build compare with Bun v1.3.14 stable?
Context
Bun v1.3.14 was published on May 13, 2026. The next day, PR oven-sh/bun#30412 merged the Rust rewrite into Bun's main branch. GitHub reports that PR as 6,755 commits, 2,188 changed files, 1,009,257 additions, and 4,024 deletions.
The PR thread says the rewrite passes Bun's pre-existing test suite, shrinks binary size, and has benchmarks ranging from neutral to faster. That is a broad claim across Bun's own matrix. This post is smaller: one machine, one stable baseline, one exact PR artifact, and the raw data checked into GitHub.
What I Compared
| Label | Source | Revision |
|---|---|---|
| bun-zig | Bun v1.3.14 stable | 1.3.14+0d9b296af |
| bun-rust | Exact PR artifact from ed1a70f81 | 1.3.14-canary.1+ed1a70f81 |
The full benchmark repository is public at https://github.com/Iamshankhadeep/bun-rust-vs-zig-benchmark. It records the exact binary revisions, SHA-256 hashes, machine metadata, scripts, fixtures, raw JSON, and rendered tables.
Machine
- MacBook Air, MacBookAir10,1
- Apple M1
- 8 cores: 4 performance and 4 efficiency
- 16 GB memory
- macOS 26.4.1, Darwin 25.4.0 arm64
I intentionally excluded serial numbers, hardware UUIDs, and other unique device identifiers from the repo and this post.
Methodology
I used Bun's documented benchmarking guidance and measured with hyperfine. The scripts never call an ambient bun from PATH; every command uses either ./bin/bun-zig or ./bin/bun-rust.
The suite covers startup, TSX build, bun:test, warm install, and five original runtime workloads: loops, JSON, strings/regex, filesystem, and a self-contained Bun.serve() HTTP test. The relative column below is pairwise, so each Zig command is compared only with the matching Rust command for the same workload.
Results
| Area | Workload | Zig stable | Rust PR | Pair result |
|---|---|---|---|---|
| Startup | bun --version | 4.39 ms | 4.25 ms | Rust 1.03x faster |
| Startup | bun eval | 10.93 ms | 10.19 ms | Rust 1.07x faster |
| Build | bun build TSX fixture | 11.57 ms | 11.91 ms | Zig 1.03x faster |
| Test | bun test fixture | 53.62 ms | 43.66 ms | Rust 1.23x faster |
| Install | warm bun install | 11.17 ms | 10.47 ms | Rust 1.07x faster |
| Runtime | loops | 17.79 ms | 17.40 ms | Rust 1.02x faster |
| Runtime | JSON | 16.78 ms | 16.61 ms | Rust 1.01x faster |
| Runtime | strings and regex | 21.72 ms | 21.51 ms | Rust 1.01x faster |
| Runtime | filesystem | 58.53 ms | 57.70 ms | Rust 1.01x faster |
| Runtime | self-contained HTTP | 30.53 ms | 22.93 ms | Rust 1.33x faster |
What Stood Out
- The clearest tooling win was
bun test: the Rust PR build ran the generated test fixture in 43.66 ms versus 53.62 ms for Bun v1.3.14 stable, about 1.23x faster. - The largest runtime gap was the self-contained HTTP workload: 22.93 ms for the Rust PR build versus 30.53 ms for the stable Zig build, about 1.33x faster.
- Startup eval and warm install were modest Rust wins, both around 1.07x.
- The TSX build fixture slightly favored the stable Zig build: 11.57 ms versus 11.91 ms.
- Loops, JSON, strings/regex, and filesystem were effectively close on this machine.
Caveats
This is not a universal Bun verdict. It is one Apple M1 MacBook Air, one macOS version, and one exact Rust PR build. Some workloads are tiny enough that startup and process setup still matter. The runtime scripts are full-process elapsed-time tests, not inner-loop nanosecond microbenchmarks.
I also did not benchmark Node.js, Deno, Linux, Windows, x64, or a real production service. The useful conclusion is narrower: for this local fixture set, the Rust PR build was already neutral to faster on most measured paths, with visible wins in bun test and the HTTP workload.
Takeaway
I expected a rewrite this large to show at least one obvious regression in a small local suite. That did not happen here. The results are mostly close, with a few Rust-side wins and one small build result favoring the stable Zig baseline.
The next useful step would be broader validation: Linux, x64, Windows, larger install fixtures, long-running server tests, and real app workloads. For now, the interesting part is that the exact PR artifact was already competitive on this M1 machine.