Overtaking Boa

JSSE v0.12.0 was tagged on October 26, a month after v0.9.0, which makes it a good point to look at the numbers again (two more releases came out while this post sat in draft, and I will get to those at the end). When I took stock of JSSE in September, the last section of that post was called “What’s Still Bad”, and it listed quadratic arrays, a bytecode VM that barely helped, no hidden classes and a benchmark that timed out. It also showed Boa beating JSSE by 2× to 4× on calls, closures and strings.

Boa is the natural yardstick for JSSE. It is a mature JavaScript engine written in Rust which, like JSSE, doesn’t JIT, and it has been around for much longer than JSSE has. Therefore, when I say that JSSE overtook it, keep in mind that this is one interpreter against another, on my benchmarks and on one machine, and not a verdict on Boa.

In this post, I will go through what happened in that month. Between v0.9.0 (September 23) and the October 25 checkpoint used for the numbers below, the agents merged 271 commits into JSSE, 84 of which are performance work¹. The short version: on my micro-benchmark suite, JSSE is about 5× faster than v0.9.0 and, while a month ago it was 2.2× slower than Boa 0.22, it is now 2.2× faster². On JetStream 3, it is faster than Boa on all 44 workloads that both engines run. And test262 still passes every one of the 99,911 scenarios.

As before, I haven’t written a line of JSSE, so this is a report on the results and not a how-to. Everything here comes from the data that lives in the repository, including the numbers that are less flattering. When the tables and charts below say “now”, they mean the October 25 checkpoint.

AXXVIStill 100%

Let’s start with the guardrail that matters the most. At the benchmarked commit, 58606ad1, I had the agent re-run the whole of test262 (the same checkout as last month) in both execution modes: 99,911 of 99,911 scenarios pass with the default configuration, and 99,911 of 99,911 pass with --no-bytecode, with zero regressions against the baseline. Going 5× faster in a month and not losing a single scenario is what the pass-list baseline is for.

BXXVIWhere the Speed Came From

Did the bytecode VM finally pay off? Yes, and it is now the default. In the last post I explained that entering a compiled function cost about 350 ns, that each op saved only about 22 ns, and that the whole thing broke even at around 16 ops. At v0.9.0, --bytecode was only 3.8% better on JetStream (geometric mean). On October 8, #875 flipped the default (it shipped in v0.11.0 the day after), and --no-bytecode is now the opt-out. My reading of the pull requests is that two things made it worthwhile: a long list of coverage PRs (generators, async functions and async generators, default and rest parameters, let loops, arguments objects), so that fewer functions fall back to the tree-walker, and a series of cuts to the cost of calls and frames.

How much of the speedup is bytecode, and how much is everything else? I asked the agent to run the micro suite once more with --no-bytecode at the same commit, so that we can split it. This is a separate run from the one in the next section, so its times don’t match that section exactly³.

Over the eight scripts that haven’t changed since v0.9.0, about 1.6× of the total (5.4× in this run) comes from the bytecode VM and about 3.4× from everything else⁴. The split is very uneven, though. The array gain is almost entirely non-bytecode work and string is mostly non-bytecode, while fib and loop are roughly half and half. opmix is the odd one out: in October the script gained two labeled loops (#876), so it does more work than it did at v0.9.0, and I leave it out of every comparison with v0.9.0. Within the October run, the bytecode VM makes it 7.7× faster than --no-bytecode, the biggest jump in the table.

The rest of the work falls roughly into five groups (all the PR numbers are in the collapsible list below):

• Bytecode and coverage. Besides #875, the generators (#1103), async functions (#1148) and async generators (#1149) are now compiled. Each of the last two cut about 30% of the instructions executed on doxbee-async and async-fs, respectively.
• Calls and frames. #1120 removed 15% of the instructions executed by fib, #1127 removed 44% on default and rest parameters, and #1134 removed between 26% and 44% on arguments objects. Between the October 14 and October 25 runs of the audit I will describe below, the default-parameter controls went from taking 2.0 to 2.2 times as long as Boa to taking 0.78 to 0.91 times as long.
• Arrays, strings and sorting. This is the one I promised in the last post. The array script went from 27.5 s to 0.18 s, mostly thanks to array work outside the bytecode VM, starting with #758, which made building the result of map, filter and slice linear. Strings got amortized O(1) concatenation (#945) and inline short strings (#1099), shift became amortized O(1) (#1195), and Array.prototype.sort now uses a merge sort that exploits natural runs (#1193).
• Generators, promises and the GC. Between the same two audits, the generators pipeline went from 1.59× of Boa’s time to 0.42×, lazy-collections from 2.05× to 0.65× and the deep promise queue from 1.10× to 0.36×. On the GC side, #1136 removed 42% of the instructions on the deep promise queue and #1137 removed 24% on Three.js.
• Everything else. jemalloc as the allocator (#1074), faster property access, BigInt, Intl caches, private fields and proxies.

Note that most of the percentages above are instruction counts (callgrind), not seconds. The seconds are in the next section.

CXXVIThe Numbers

Let’s look at the same nine scripts as last time. Each one is timed as a whole process (startup included), and we take the median of five interleaved runs. This time Boa shows up twice: version 0.22.0, which I used in the last post, and its current main (commit 64c209f1, which still calls itself 0.22.0), so that nobody can say I compared against something stale. Tick the boxes to add or remove engines from the comparison.

Against v0.9.0, JSSE is 4.3× faster on fib, 4.2× on closures, 10× on string and 154× on array, with a geometric mean of about 5× over the eight scripts that haven’t changed (the chart leaves out the v0.9.0 opmix bar for the same reason). Against Boa 0.22.0, it now wins all nine: the narrowest margin is fib (0.78× of Boa’s time) and the widest is string (0.20×). The geometric mean of the time ratio is 0.47 against Boa 0.22.0 and 0.50 against Boa main. Startup, measured with an empty script, is about 16 ms for JSSE and about 30 ms for Boa.

JetStream is again the more realistic set. JSSE passes 48 of 48 workloads (mandreel, the one that timed out in the last post, now runs). Boa 0.22.0 and Boa main both pass 44, and fail Basic, OfflineAssembler, typescript-octane and validatorjs. On the 44 workloads that both engines run, JSSE is faster on every single one. The chart shows the time ratio per workload (JSSE’s time divided by Boa’s, drawn from 1.0 down to the ratio, so the longer the bar, the bigger the JSSE win)⁵.

The geometric mean is 0.56 against Boa 0.22.0 (JSSE is about 1.8× faster) and 0.53 against Boa main (about 1.9×). The biggest wins are json-stringify-inspector at 0.11 (the benchmark that regressed in the last post, which is now about 9× faster than Boa) and the inspector and js-tokens workloads at 0.17 or 0.18.

The third set of numbers is a 343-case audit that the agent runs against Boa main. It combines JSSE’s own benchmark scripts and diagnostics, Boa’s own benchmark scripts, JetStream workloads and paired control micro-benchmarks written for the audit. Of the 343 cases, 328 run on both engines. Compared with the previous audit of October 14, the geometric mean of JSSE over Boa went from 0.75 to 0.56, the number of cases where JSSE is more than 5% slower went from 93 to 14, and the number where it is more than 30% slower went from 38 to 5⁶. A suite of 61 short scripts, each exercising one language or library feature in a loop, agrees: JSSE is faster than Boa 0.22.0 on 49 of the 61 and faster than Boa main on 53.

DXXVIWhere Boa Still Wins

None of this means JSSE is faster than Boa at everything. At the checkpoint, 14 audit cases were still more than 5% slower than Boa main, and ten of them fall into four groups:

• bigint_compare_numeric_control (1.89× Boa’s time), script_let_loop (1.82×), bigint_compare (1.60×) and three more, all top-level script loops over global lexical bindings, tracked in #1210, which has since been closed.
• Closure creation (closures/create, 1.42×), tracked in #1211, which has since been closed.
• Getter and setter calls (about 1.2× on the proxy case, and 1.07× on proxy_ownkeys_has), tracked in #1212.
• strings/slice (1.33×). It is a curious one: JSSE executes fewer instructions than Boa (529M against 652M), and which engine wins the wall-clock race depends on the CPU, so I believe it is a memory-system effect and not a real gap.

The other four are smaller gaps, between 1.09× and 1.16×, which have no issue of their own: BigInt invert, mulmod256 and ops_vm_add, and str_keys_control.

On JetStream, the narrowest wins are bigint-noble-secp256k1 (0.91), proxy-vue (0.87), bigint-noble-ed25519 (0.86) and richards (0.82). The margin also depends on bytecode: with --no-bytecode, JSSE is only about 1.16× faster than Boa 0.22 over all nine micro scripts (geometric mean 0.865), and it is slower on opmix (4.2×) and fib (1.7×). And at the checkpoint, hidden classes still hadn’t landed: there were per-site slot hints and cached property order, but no hidden-class transitions. Boa, for comparison, has had hidden classes since v0.17.

EXXVISince the Checkpoint

This post sat in draft for longer than I intended, so the numbers above are no longer the whole story. JSSE v0.13.0 came out on November 1 and v0.14.0 on November 8. I haven’t re-run the full set of benchmarks against either of them, so everything above describes the October 25 checkpoint and nothing later.

Three things in the previous section have already changed. The issue for the top-level script loops, #1210, was closed by #1302, which shipped in v0.13.0. The issue for closure creation, #1211, was closed by #1593 on November 9, after v0.14.0, so that change is waiting for the next release. On a reduced test case it brings the instruction count close to Boa’s (644M against 636M), although Boa is still ahead on wall-clock time there (51 ms against 58 ms). And JSSE now has shapes with transitions, for objects that start out empty: #1556, which also shipped in v0.13.0. However, that was memory work and not speed work, since the inline caches still match per object and not per shape.

FXXVIWhat’s Next

The audit gaps are collected in the epic #1213, which is still open and remains the next target. After that, I would like to see the inline caches match on shapes, which is where I would expect the speed benefit to show up.

All the numbers come from docs/perf/2026-10-25 and docs/perf/2026-10-25-no-bytecode⁷.

GXXVICorrections or Comments?

Comments are open below. As usual, I am happy to receive corrections, and if you spot something odd in the numbers, open an issue on JSSE.