Benchmarks

Real timing and memory numbers comparing Cruft 0.0.10 against Node, Bun, and Deno across every benchmark suite. Shows where Cruft runs slower today (compute-heavy loops, package installs, SQL throughput) and the few places it is already competitive (hot numeric loops, HTTP handlers, startup memory).

Cruft is an alpha runtime. Its execution core is an interpreter (Exegesis) with a single baseline JIT (LeJIT) and no optimizing tier above it, so on most workloads today it runs slower than the mature V8-based runtimes. This page is the honest measurement of how much slower, and of the few places where it is already competitive.

The numbers below are real, not projections. They come from Cruft's own benchmark harness run across every suite against Node, Bun, and Deno.

How this was measured

Harness: cruftbench run --suite all, comparing cruft, node, bun, and deno on the same fixtures.
Engines: Cruft 0.0.10, Node v22.22.3, Bun 1.3.11, Deno 2.7.7.
Machine: an Apple M1 MacBook Pro (macOS, arm64).
Values: medians of repeated runs. In the ratio tables, a value is Cruft's speed relative to the peer, so greater than 1 means Cruft is faster (for memory rows, greater than 1 means Cruft uses less), and less than 1 means the peer wins.

The headline

Bun is the fastest engine measured, across nearly everything. Against Node and Deno, Cruft is mixed: it trails on broad microbenchmarks, package scripts, GC churn, SQL throughput, and pure-compute loops, often by a lot; it is roughly Node-class on everyday async and array work; it is faster than Node on JIT-friendly numeric loops and on the HTTP-server fixtures; and it starts using less memory than Node or Deno.

Workload	vs Node	vs Bun	vs Deno
Numeric / array loops (JIT-friendly)	1.65x	0.83x	—
HTTP server handlers	1.25x	0.85x	1.09x
Web tooling (build-shaped)	0.97x	0.42x	0.85x
Everyday broad microbenchmarks	0.22x	0.14x	0.27x
Node core-API throughput	0.18x	0.45x	—
Worker fan-out (wall time)	0.60x	0.20x	0.61x
Package install / run	0.32x	0.14x	0.27x
GC-churn allocation loops	0.05x	0.04x	—
SQL query throughput	—	0.16x	—
Pure-compute corpus	0.001x	0.002x	—
Startup time	0.89x	0.36x	0.68x
Startup memory (less is better)	1.42x	0.82x	1.80x

The extremes are the honest ones. On the pure-compute corpus, tight math with no I/O, Cruft is roughly a thousand times slower than Node: this is the shape of work an optimizing JIT is built for, and Cruft has none. On the other end, at startup Cruft's resident memory is well under Node's and Deno's.

Concrete numbers

Wall time in milliseconds, lower is better. These are individual fixtures, to make the ratios above tangible.

Where LeJIT engages (tight numeric and array loops):

Benchmark	Cruft	Node	Bun
`numeric_i64_sum`	46.0	75.8	32.8
`array_affine_read`	38.1	73.0	33.8
`object_property_read`	48.0	68.2	30.3

Here Cruft beats Node and comes within reach of Bun, because the loops are hot and typed enough for the baseline JIT to specialize them.

Broad, mixed work (node/bun/deno/cruft):

Benchmark	Cruft	Node	Bun	Deno
`cold_start`	37.2	65.0	31.2	54.3
`promise_chain`	68.2	61.4	29.1	70.7
`array_callback_pipeline`	82.1	81.3	40.6	72.7
`arith_tight_loop`	265.7	98.0	58.9	84.0

Cold start and everyday async/array work land near Node. arith_tight_loop is the cautionary one: a compute loop the JIT does not specialize runs several times slower than every peer. That gap is exactly the optimizing tier Cruft does not have yet.

Startup (time in ms, memory in MB):

Benchmark	metric	Cruft	Node	Bun	Deno
`trivial`	startup ms	41.2	48.6	20.7	37.3
`trivial`	peak RSS MB	27.6	41.4	21.4	51.8

Cruft's startup time is close to Node's and behind Bun's, and its startup memory is lighter than both Node's and Deno's.

What to take from this

Cruft is not fast yet, and on compute-bound and throughput-bound work it is clearly behind Node, Bun, and Deno today. What the numbers also show is that the gap is not uniform: the baseline JIT already carries hot numeric loops to Node-or-better speed, the server and startup paths are competitive, and per-realm memory is a genuine strength (see the worker-scaling numbers under Trash Panda).

The reason to read these as a floor rather than a ceiling is the engine's design: correctness is the fixed invariant and speed is the young axis. Exegesis is the semantic source of truth, and every optimization only has to match it, so performance work can proceed without risking behavior. The optimizing tier that would close the compute gap is future work. The gap is a property of the engine's age, not of the design.

Measured 2026-07-30 on an Apple M1 MacBook Pro. Re-run cruftbench run --suite all to reproduce; results will shift with hardware and with each engine's version.