LOOK vs Node.js vs PHP — the honest numbers.

How we measured — and what we threw out

A benchmark is only as good as its setup. During this work we caught seven confounds that would each have produced a wrong headline. The discipline was simple: a claim is a hypothesis until a clean, isolated measurement confirms it. Reading the source generates ideas; measurement decides.

Workload 0 — the language core (pure CPU, no HTTP)

Before any web framework, how fast is the language itself? Seventeen micro-benchmarks — arithmetic, loops, function calls, strings, arrays, maps, JSON, exceptions — each implemented identically in LOOK, Node and PHP, run with an integer checksum that must match across all three (a mismatch means the implementations diverged, not a result). This is LOOK's hardest arena: a bytecode VM interpreting each operation against V8's and PHP's JITs, with no I/O to amortize. We publish it as-is.

Node's JIT wins the compute microbenchmarks, mostly by 8–40× — that is structural: it compiles each hot loop to machine code, LOOK interprets it. Two honest caveats keep the table fair. exception is the one LOOK wins outright — 26× faster than Node — because throwing is cheap in LOOK and expensive in V8; real request-handling code throws far more than it runs tight arithmetic loops. And regex is not an engine-speed number: ~95% of that time is a ReDoS safety guard (a per-call thread bounding catastrophic backtracking), not matching — the raw match is ~1.9 µs/call.

Why this rarely shows on the web: the VM's per-instruction dispatch is about 0.5% of a real request's cost (≈0.4 µs of ~90 µs) — the rest is HTTP parse, routing and response building. A microbenchmark magnifies the one layer that barely moves the needle in production (Workloads 1–2 below). It is published because hiding your worst arena is not measurement-first.

Re-verified this cycle. A fresh three-way run reproduced every row — all 17/17 checksums matched and the LOOK÷Node ratios held. The only movement was a few-percent rise on the arithmetic rows (int_arith, loop, float_arith), which tracked the test laptop's thermal state under sustained load (the numbers climbed monotonically across back-to-back runs while the engine was unchanged) — machine drift, not a language change. So the representative numbers above stand rather than being overwritten with warm-machine noise.

Where it improved — and where it regressed

The question "did the language get faster or slower?" is only answerable by comparing the previous build against the current one in the same run (drift cancels; a correctness suite can't see speed). We do exactly that every cycle. This one moved four numbers:

No functional test — not even our three-engine differential suite — catches a codegen-layout regression like that; only an old-vs-new speed scan does. So it became a permanent rule in the harness: any change to the opcode set or the dispatch loop must ship with an old/new regression scan. This was the fourth time this session a real defect lived in a behavior no test was asserting.

Workload 1 — trivial JSON (CPU-bound)

A route that returns {"ok":true,"msg":"hello"} — no I/O, pure runtime overhead. This is LOOK's worst case: nothing amortizes the interpreter, so a JIT (V8) has the largest possible edge. We show LOOK both at its default worker count (throttled) and correctly tuned.

Node wins raw throughput ~4× — V8's JIT compiles the trivial handler to near-native code; LOOK's bytecode VM interprets it. That's structural and expected. But look at p99 @ c=1000: Node's tail collapses to 1.17 s while LOOK (tuned) holds 212 µs — and LOOK does it in 1.85 MB of RAM against Node's 91 MB.

Workload 2 — database endpoint (I/O-bound)

The real web workload: SELECT id,name,email FROM users WHERE id=? → JSON, against MySQL 8.4 (kept at 0.5–1% CPU, so the database is never the bottleneck). LOOK uses its embedded driver + async pool; Node uses mysql2; PHP uses mysqli — each in its production shape.

With real I/O the gap narrows — Node ~1.6× LOOK's throughput, LOOK ~4× PHP's. And again the tail inverts under load: at c=1000 LOOK's p99 is 0.87 ms vs Node's 383 ms, in 2.5 MB vs 234 MB of RAM.

Worker sweep (the data behind LOOK's default): I/O-bound peak is w=4 (9,487 req/s, p99 0.87 ms). w=2 leaves throughput on the table (6,607); w=8 over-throttles (7,240, p99 44 ms). The optimum is workload-dependent — CPU-bound wants ≈ the quota, I/O-bound a little more.

The real story — tail latency under load

Production isn't measured by "requests per second" alone; it's measured by what your worst user waits. This is where the two designs diverge most. As concurrency climbs, Node's p99 curves sharply upward — it is buying throughput by queueing. LOOK (tuned) stays a flat line.

We deliberately avoid quoting the raw ratio ("5,500×"): the two systems are in different regimes at c=1000 — Node is saturated and queueing, LOOK is not. The honest statement is the shape of the curve: LOOK does not enter saturation where Node does.

Does LOOK hit a ceiling? Not on tail.

At c=1000, LOOK (tuned) is at 22k req/s with p99 212 µs and zero throttling — comfortable, not saturated. So we pushed both runtimes to 5,000, 10,000, then 20,000 concurrent connections — same tool, same box, so no one can say we only stressed one side.

Measured symmetrically, the trade is stark: Node sustains ~3–4× the throughput (65–87k vs ~22k) — but its p99 sits in whole seconds (1.36–2.41 s) while LOOK holds a flat ~190 µs from 1,000 to 20,000 connections. Two threads, 20,000 connections, sub-millisecond tail. Neither runtime "breaks" — they occupy opposite corners: Node maximizes throughput and pays in tail; LOOK holds latency and caps throughput at what two interpreted cores can do (~22k).

Both runtimes dip at c=20,000 (LOOK 22k→17k, Node 81k→65k) — that is the single load-generating machine hitting its own limit (ephemeral ports / one wrk host driving 20k live sockets), not either server failing. The proof: LOOK's p99 is still 196 µs at that point, and Node's actually improves as its in-flight backlog thins. On a real fleet the client load would come from many hosts.

Stability — we sent it 10.5 million requests

Throughput and latency mean nothing if a server drifts, leaks, or falls over. So we ran three endurance tests and watched the process the whole time — resident memory, error counts, restart and OOM flags.

10,558,613 requests over 8 minutes: RSS identical before and after, p99 flat at 219 µs, zero crashes, zero leaks, zero OOM kills. LOOK finished exactly as it started. This comes from the design — a single binary, a fixed worker pool (no thread-per-request), and no per-request allocation growth — so 20,000 live connections are held in 7 MB. For comparison, the Node database server in the same box sat at 234 MB.

The honest verdict

There is no single winner — there are three axes, and each runtime is built for a different point.

If your metric is maximum requests per second on a trivial CPU-bound path, Node's JIT wins. If your metric is what your worst user waits under load, how much memory a fleet costs, or whether it's still standing after ten million requests, LOOK is the design that holds — predictable, tiny, and it doesn't fall over. PHP trails on throughput in both workloads.