Benchmarks

Standard Web APIs, the same script on each runtime (n/a where a runtime lacks one). Lower is better. esrun pairs near-instant startup with full WinterTC coverage and a JIT engine.

Runtimes measured

Standings at a glance

Who placed where across every metric — and a quick, neutral take on where each runtime fits in production. Pick by fit, not by medal count.

Startup & footprint

Process wall-time (min of N runs). bigscript is one large file, modules a 300-module graph — parse cost and resolution cost are not the same thing. Memory is given twice: idle, and while a live working set is retained.

Engine

Self-timed with performance.now() after an untimed JIT warmup; min of N interleaved runs, isolating engine cost from process launch.

Web APIs

Crypto

Hashing

crypto above measures crypto.subtle — asynchronous, and returning bytes a caller still has to encode. These rows measure what that caller wanted: runtime:hashing for esrun, Bun.CryptoHasher for Bun, and node:crypto createHash for Node, Deno and LLRT. hash_fast has no standard answer in Node, Deno or LLRT, which is why they are n/a.

Network

HTTP server drives each runtime's own server from a client in the same process, so it measures the server and that runtime's fetch together, not the server alone. For server throughput on its own, bench/rps.sh uses an external load generator on separate cores.

Hello world, measured externally

A JSON hello-world response through Hono per runtime, driven by an external load generator on separate cores. LLRT has no general HTTP server, so it is not in this set. The memory column is peak RSS for the whole server process during the run, not JavaScript heap alone; it includes the runtime, framework, and server path. This measurement shows the footprint but does not attribute it to a specific layer.

Hono hello-world · Speed & Memory

Burst60s Sustained

Runtime

Throughput (higher ↑)

Memory (lower ↓)

Bun

70.2k

45 MB

Deno

73.3k

51 MB

esrun

48.9k

53 MB

Node.js

30.1k

111 MB

Burst vs sustained

The chart above is a burst against a freshly started process. Held under load instead, the heap is full and the collector has been running throughout.

Static files, measured externally

A 64 KiB file per response, driven by an external load generator on separate cores — the server alone, unlike the in-process row above. Bun and Deno hand a file handle to the kernel; Node streams it; esrun reads it host-side, outside the JavaScript heap.

HTTP requests/sec · 64 KiB static file

Runtime

Throughput (higher ↑)

Memory (lower ↓)

Bun

29.8k

35 MB

Deno

14.1k

152 MB

esrun

19.3k

65 MB

Node.js

11.9k

282 MB

Filesystem

Page-cache resident, no fsync — this is the runtime's cost above the syscall, not disk speed. Numbers are specific to the filesystem in environment.

System

Starting a child process and collecting its output — Deno.Command, Bun.spawn, node:child_process, and esrun's runtime:system Command.

Tracing and async context

Measured separately, by bench/probe-tracing.sh, and shown where the design is explained:

• Async context — propagation cost against Node, Bun and Deno, and the promise-hook overhead that is a known gap.

• Diagnostics — one op with nothing subscribed, with a subscription, and under --otel.

Behaviour under memory exhaustion

What happens when a script asks for more than the machine can give. The question is not speed but whether the guest survives: a catchable error is a failed request, a signal is a dropped process.

Native vs third-party parsers

Each runtime parses with the best facility it ships: esrun's runtime:serialization, Bun's native Bun.YAML and Bun.TOML, LLRT's llrt:xml. Node and Deno ship no parser for these formats, so they use the libraries you would reach for anyway (js-yaml, @iarna/toml, fast-xml-parser, msgpackr) — a native-vs-library gap on those rows, not a runtime-vs-runtime one.

Protobuf (each runtime's own path)

esrun decodes with its native runtime:serialization Protobuf (pure-JS, reflective); Node, Bun, and Deno decode with protobuf-es (@bufbuild/protobuf). Identical bytes, each runtime's real protobuf path.

WebAssembly

esrun reaches V8's own WebAssembly implementation through the standard JS API, as Node and Deno do; Bun uses JavaScriptCore's. LLRT has no WebAssembly at all, so every cell here is n/a for it.

The three measure different things. Compile is validation plus baseline codegen on a ~250 KB module, with a different salt each iteration so nothing is served from a code cache. The call boundary (20M calls into a trivial exported add) and linear memory (JS fills a 64 KiB window, wasm sums it back) are where real interop spends its time. These workloads exercise different parts of V8; compare each row separately, since their rankings differ.

WASI

wasm32-wasip1, which is what a compiled CLI targets. Bootstrap is 2,000 x (construct a WASI, instantiate a command module, run _start) with compilation hoisted out, so it is the per-invocation cost of running a wasm program. Syscalls runs a guest whose _start loops 20,000 times over random_get and clock_time_get — the calls come from inside wasm, where a real program makes them, so it measures the host-side preview-1 implementation.

esrun's bootstrap is the fastest measured, a little ahead of Deno and several times quicker than Node or Bun. Its syscall path is not: Deno's is around 3x faster, because esrun implements preview-1 in JS rather than natively. Bun is also faster on that workload in the current sample.

WebSocket chat broadcast

C clients in one room; the server fans every message out to all of them. Cells are RECV messages/sec (fan-out), best of 3. Higher is better.

Server fan-out

Each runtime's built-in server, fixed Bun client driver. Node has no built-in WS server, so it's not in this sweep.

esrun serves through the capability-secured driven seam (each connection a spawned actor), not a native pub/sub server. A batched broadcast() leads at low fan-out; as C grows the central connection-map lock costs throughput while Bun/Deno hold flat.

Client throughput

Fixed Bun server; each runtime's WebSocket client under the same broadcast load — esrun lands on par with node, Bun and Deno.

See the WebSocket guide.

HTTP/1.1 vs HTTP/2

Each runtime's hello-world server is measured over HTTP/1.1 and cleartext HTTP/2 (h2c), where supported. Node and Bun use separate server APIs for h2 because their default servers do not support it; their ratios therefore include an implementation change as well as the protocol change. Cells are req/sec, best of 3 interleaved repetitions. Higher is better.

Unlike the charts above, this table is driven by an external load generator against each runtime's own server, and it is regenerated on its own (bench/http2.sh) rather than as part of the full sweep — so treat it as a separate run, not as another row of the same experiment.

Two shapes, because an HTTP/2 number on its own says nothing — it is dominated by how the client connected:

• Wide (50 connections, 1 stream each) is HTTP/1.1's best case: it already has 50 sockets, so there is nothing to multiplex and h2 is pure framing overhead. Every runtime loses here, esrun least of them.

• Narrow (1 connection, 50 streams) is what HTTP/2 is for. HTTP/1.1 on one connection is strictly serial — the next request goes out only after the previous response comes back — while HTTP/2 carries all 50 at once. This is the shape a reverse proxy, an API gateway, or a gRPC client is in.

esrun leads the narrow HTTP/2 column outright, from the slowest HTTP/1.1 baseline on that shape: runtime:http hands responses back per request rather than per connection, so multiplexed streams could always complete out of order and the feature needed no new machinery to exploit.

See the HTTP/2 section of the HTTP guide.

Redis clients

esrun with @opentf/esrun-redis against Bun's built-in RedisClient and, on Node and Deno, both npm clients — redis (node-redis, the official one) and ioredis (roughly twice the downloads). Both are kept because they do not perform alike, and standing one in for the other would misreport Node.

Wall ms, min of 5, lower is better. Every workload prints a checksum the runner compares; all six columns agreed on all five.

Peak RSS, MB:

Bun's client leads everything, by 1.3× on the round trips and 3–5× where decoding dominates. It is native C++ against four JavaScript clients, and the gap is what that buys.

Among the JavaScript clients, esrun is fastest where the round trip dominates — 858 ms against node-redis's 1029 and ioredis's 910 — and does it in a third of the memory (38 MB against 79–124). It is also ahead of the official node-redis on the batch (225 vs 374) and the list scan (158 vs 203).

One workload is a genuine loss: repeated HGETALL at 957 ms against ~480 ms for both npm clients, twice as slow. That is not decoding in general — the list scan is mid-pack — it is specifically the map path.

Unlike the rest of this page, these runs are not interleaved — each column is measured in turn — so treat small differences as noise and the order of magnitude as the finding. Reproduce with bench/db/redis/run.sh.

Images

Each runtime's own way of making a thumbnail: runtime:images for esrun, Bun.Image for Bun, createImageBitmap with an OffscreenCanvas for Deno, and, since Node.js has no image API, sharp (libvips), which Node applications use. Every workload starts 40 pipelines at once, which is how a server meets uploads. Each runtime uses its defaults, including its thread pool. Wall ms, min of 5, lower is better; n/a where a runtime cannot write the format. Every workload prints a checksum of the output dimensions, and the runner refuses a run in which they disagree.

Size of one output. Encoders trade speed against size, so a time is only comparable between outputs of similar size. Every runtime is asked for quality 80.

Peak resident memory of the whole process, lower is better:

esrun's codecs are otf-pixels' own, written in Rust; Bun and sharp use C libraries (libjpeg-turbo, spng, libwebp; libvips with mozjpeg, libpng, libwebp, and libheif with libaom). Deno's encoder writes PNG and JPEG only. Where esrun is slower, the time is in Pixels' codecs; see Internals: images. Reproduce with bench/images/run.sh.

Reproduce

The harness lives in bench/. It auto-detects installed runtimes and can emit the JSON that powers these charts:

# human-readable table
bench/run.sh

# one section only — see `bench/run.sh --list`
GROUP=fs bench/run.sh

# regenerate the data module this page renders
bench/gen-bench-data.sh

# one section, or a few rows, merged into the rest
SECTIONS=rps_sustained bench/gen-bench-data.sh
bench/gen-bench-data.sh regex strings

# just the HTTP/1.1 vs HTTP/2 table
bench/http2.sh

For CLI/script benchmarking, tools like hyperfine are also a good fit. Numbers vary by hardware; treat them as relative, not absolute.