Zinc vs QuickJS vs Node.js — performance report

Generated by node scripts/bench.mjs on 2026-09-28T06:02:51.193Z.

Methodology

• Machine: Apple M1 Pro, macOS 15.7.4
• Zinc: this repo, native target = macOS release (--release), sim target run with node
• Node.js: v24.14.0 (node <kernel>.ts, native TypeScript type-stripping, no JIT warmup beyond one process lifetime)
• QuickJS: QuickJS version 2026-06-04 (qjs <kernel>.js, types stripped with Node’s built-in node:module stripTypeScriptTypes, an interpreter with no JIT — this is the engine PocketJS embeds, so these numbers are also PocketJS’s scripting cost)
• C++ compiler: Apple clang version 21.0.0 (https://github.com/swiftlang/llvm-project.git 11673e6660b2d0a5f9f99b1c7b773f4c2f6df1b0)
• Each kernel/engine pair: 5 runs, wall clock via process.hrtime around spawnSync, median reported
• Peak RSS: one extra run per engine wrapped in /usr/bin/time -l, “maximum resident set size” (not counted in the median timing, to keep the wrapper’s overhead out of the timing numbers)
• Every kernel prints exactly one line (a numeric/string checksum, or one JSON blob); the harness asserts all four engines print byte-identical output before recording a result
• Kernels live in tests/bench/kernels/*.ts; several were tuned down from the canonical Benchmarks-Game sizes so QuickJS (no JIT) finishes in reasonable time — each file documents its deviation in a header comment, and it is repeated in the Deviations section below
• Reproduce: node scripts/bench.mjs

Wall-clock time (median of 5 runs, ms)

Peak RSS (/usr/bin/time -l, KiB)

Zinc native binary size

Startup cost and minimal-binary size (empty program)

Checksums match across all four engines: yes (empty program prints nothing).

PocketJS AOT path (microts)

A clone of PocketJS (commit 25081f6) was inspected at the scratch path given in the task. Its microts compiler (microts/compiler/cli.ts, run with bun) is not a general-purpose TypeScript-to-Rust AOT compiler for arbitrary algorithmic code: its own CLI router only accepts build|check|run <app-dir>|Root.vue|App.tsx — a reactive UI component (Solid/Vue-style, JSX or SFC) that lives under apps/<name>/, compiled against PocketJS’s model/board/tape runtime (aot-model-*.ts, aot-browser*.ts, aot-jsx-text.ts, vendor/vue-vapor-ir.ts).

Concretely: bun microts/compiler/cli.ts check tests/bench/kernels/fib.ts is rejected outright by the CLI’s own argument router (MicroTS: expected build, check or run) because a plain .ts file with no JSX/SFC and no apps/ scaffolding is not one of the three accepted input shapes. Porting fib/nbody/mandelbrot/etc. into a PocketJS reactive-component shape (state, template, DOM/board semantics) would not be measuring the same thing as the other three engines — it would be authoring throwaway UI apps around trivial computations, which is out of scope for a scripting-cost comparison and not achievable meaningfully within the ~20 minute budget for this investigation.

cargo/rustc (1.x, from rustup) and bun are installed, so the Rust toolchain itself is not the blocker; the blocker is that microts targets PocketJS’s UI component model, not headless scripts.

Since PocketJS’s own JS runtime (non-AOT path) is QuickJS, the QuickJS numbers in the wall-clock table above are PocketJS’s scripting cost for any code it interprets rather than compiles through microts — which is the honest proxy the task asked for when the AOT path is not reachable.

Analysis

• Geometric mean over the 10 kernels above: Zinc native is ~13.1x faster than QuickJS and ~4.3x faster than Node.js on median wall time (arithmetic means of the ratios, 25.8x and 6.3x, are inflated by nbody and spectralnorm). The spread is wide: the largest QuickJS gap is nbody at 80.4x (QuickJS’s interpreter loop, with no JIT, pays full per-operation dispatch cost on every iteration of a tight numeric loop), and the smallest is strings at 2.1x (this kernel’s cost is dominated by something other than raw loop throughput — allocation, string building, or I/O — where the interpreter/VM overhead matters less).
• Where Zinc loses outright: fannkuchredux (Node.js is 1.4x faster than Zinc native). This is V8’s tiered JIT doing its job: once a hot loop is identified and optimized, V8 emits native machine code competitive with (here, faster than) Zinc’s AOT-compiled C++ — V8’s optimizing compiler can specialize on the runtime shapes/values it observes as a function gets hot, something Zinc’s ahead-of-time C++ codegen does not do. Zinc still wins nearly everywhere else because it has zero warmup cost and Node pays JIT compilation + deopt-guard overhead on every fresh process, but a single benchmark kernel is exactly the case (short warmup window, one hot loop) where V8’s JIT is at its best relative to an AOT compiler.
• String-heavy and Map/Set-heavy kernels favor Zinc less than pure-arithmetic kernels versus QuickJS specifically (see jsonout and strings above): Zinc’s runtime strings and containers still pay allocation/refcounting overhead per operation, and QuickJS’s string/object primitives are a mature, tuned part of that interpreter, so the gap for allocation-bound kernels is much smaller than for arithmetic-bound ones.
• Startup and binary size are the clearest structural win for Zinc: the native binary has no VM to initialize and links only the small zrt runtime, versus QuickJS which still has to construct a full JS heap/interpreter on every process start (see the startup table), and versus a qjsc-compiled standalone hello-world that statically bakes in the whole QuickJS engine.
• Memory: peak RSS numbers in the table above should be read with the usual caveat that /usr/bin/time -l measures the whole process (including Node’s/QuickJS’s own startup heap), not just the kernel’s working set — Zinc native’s RSS is dominated by the kernel’s own allocations since there is no VM, which is why it is consistently the smallest number in that table, often by 1-2 orders of magnitude.

Deviations from canonical Benchmarks-Game sizes

All other kernels (fib, spectral-norm, strings, Map/Set, sort, JSON) run at or above the sizes given in the task.

Edit this page on GitHub ↗