Where Bun's 3x Speedup Disappears (and How to Benchmark It)

Bun's "3x faster than Node" figure came from a summary-level article that never named the hardware, the workloads, or a harness. This video walks through the reproducible benchmark harness I built to test it: pinned runtime versions, a digest-locked base image, warmup iterations that are discarded before any percentile, and a failure rule that voids a cell when a response isn't a success. Measured spawn-to-exit startup, 200 iterations after 20 warmup runs, on an 8 vCPU Ubuntu 24.04 container: - hello.js: Node 22.14.0 at 38.2 ms median, Bun 1.2.5 at 20.9 ms, about 1.8x - cli.ts with strip-types versus native TypeScript: 127.6 ms versus 33.8 ms, about 3.8x - cli-heavy.ts: 209.4 ms versus 187.2 ms, the gap narrows sharply once a large module graph is in play The speedup shrinks or disappears when something other than the runtime primitive dominates the work: native addons that call the same C++ on both runtimes, APM built on async_hooks, sustained TLS traffic, a database round trip in the hot path, and long-lived heap behaviour after a soak test. Labels used throughout: [source] for claims from the original reporting, [measured] for numbers that came out of this harness on a stated machine on a stated day, and [inferred] for explanations that were not proven with a profiler. The full write-up, the workload matrix, the runner and probe code, and the JSONL results are here: https://hackyjs.com/posts/where-buns-3x-speedup-disappears-a-reproducible-benchmark-harness-for-nodejs-workloads

bunnodejsbenchmarkingperformancejavascript

Read the post →