Benchmarks

How fast does djs start, run and dump the scripts an agent writes, and what does it cost in download and memory, next to the QuickJS builds a host would otherwise embed? This page compares them on workloads modeled on real agent codemode sessions, all in WebAssembly, the way a host runs them, and says how to re-run every number.

In short. Seven engines (djs, four QuickJS builds of both QuickJS lines, and monty, a Python subset) run nine codemode workloads in wasm in one node process, each run in a fresh VM, and must all return the same result. djs starts a VM fastest and has the lowest run time over the set; it is ahead where scripts move JSON, strings and tool results, and behind on the smallest bodies and on some single string builtins. Passing data through the host bridge, each engine its best way, djs takes values in about twice as fast and reads them out about ten times as fast; it is behind on bytes coming in and on many tiny calls. Its module is the largest of the JavaScript engines and it takes more memory than the QuickJS releases built here, and its dumps of a paused run are kilobytes, written or loaded in under a millisecond for most workloads. scripts/bench-engines.sh fetches, builds and runs everything; the tables and charts are generated from the recorded results.

What is measured, and why this way

An agent’s codemode body is short and makes a few tool calls: it reads files, runs commands, reshapes their output and prints a summary. The engine’s own work is small, so what a host pays is mostly starting a VM, passing tool results in and out, parsing the body and assembling strings. The comparison measures exactly that, as an embedder sees it:

• Everything in wasm, in one host. Every engine is a wasm module run by node: the build a host would ship, not a native binary. Each module is compiled once per process, as a host keeps a compiled module.
• A fresh VM per run. Every run gets a new instance and VM, isolated from the others, as a host gives each tool call its own sandbox. New VM is the time to get one ready; run is the time from handing it the script to having the result string.
• A warm process. The times are medians of 25 runs after 3 warm-up runs, so node has optimized each engine’s code, as in a host that has been running for a while.
• The same tool bridge. Tool answers are recorded once and handed to every engine as one JSON string; inside the engine, each tool call turns its arguments into JSON to find its answer and parses the answer’s JSON text. That is the work a host bridge does, and it is the same code in every engine, so the comparison measures the engines and not their host interfaces. Passing data through the bridge compares the host interfaces.
• The same answer. Every engine’s result must be the string node computes for the same script, or the run fails.
• Memory is the instance’s linear memory after the run. Wasm memory never shrinks, so that is the run’s high-water mark, allocator overhead included.

Times depend on the machine and its load; the tables say when and at what load they were taken. Instruction counts would not compare across engines with different hosts, so the page gives wall-clock medians.

The engines

The two latest QuickJS releases are built by the script with one compiler, the same flags and the same small embedding (js/bench/engines/driver.c): a runtime, a context, an evaluation that runs the job queue dry, and a result string. monty runs the workloads translated to Python by hand; its component is instantiated on the calling thread with no filesystem, environment or network, as its own worker does.

The workloads

The workload set (tests/bench/codemode/) was derived from about three thousand codemode bodies of agent sessions: they were grouped into clusters by what they do, and each cluster got one synthetic body of its typical size and operation mix. The data the tools return is invented: source-like files, command output, search results, query rows, an image.

A typical body is about 500 characters and makes three tool calls; the workloads sit at or a little above their cluster’s median, so that the engines’ work shows.

Download size

What a host ships: the wasm module, and the JavaScript some builds need around it.

Module bytes as shipped; gzip -9, brotli quality 11; measured at 1268c57eeb, 2026-11-06, load 2.3.

djs’s module is the largest of the JavaScript engines: it carries the TypeScript front end and the base image of an initialized realm (every builtin object, coded to

quickjs-wasi and the emscripten builds are optimized for size; the two releases built here use -O2, as djs’s module is optimized for speed. monty’s module is a different order of size altogether: a Python interpreter with its standard library subset and a type checker.

Starting a VM

A host that gives every call a fresh VM pays this on every call.

Compile: the module, once per process. New VM: a new instance and VM, ready to evaluate (median). Memory: linear memory; measured at 1268c57eeb, 2026-11-06, load 2.3.

A new djs VM is ready in 0.12 ms, against

comes from the base image in the module, so creating a VM copies an image instead of running the code that builds every builtin (the snapshots page says how). Its idle memory is above the QuickJS releases’: the base image is larger than the heap a fresh QuickJS context allocates, and djs reserves a larger native stack, which sets how deeply its parser may nest. The emscripten builds start at 16 MiB, emscripten’s initial heap, whatever runs in them.

Run time

The time from handing a fresh VM the script and its tool answers to having the result: parsing and compiling the body, the tool calls through the bridge, and the script’s work.

Milliseconds per run (median), in a warm process; the last row is the geometric mean of each engine’s time over djs’s; measured at 1268c57eeb, 2026-11-06, load 2.3.

djs has the lowest time over the set, and the largest leads where a body moves data: fanout, json and media pass large tool results through JSON.parse and strings (djs parses and writes JSON in about a third of QuickJS’s time, see the operations below), and heavy spends most of its time splitting, matching and scanning file texts. loop is a regular expression replace over prose in a loop, where Bellard’s QuickJS is close and QuickJS-NG and quickjs-wasi are far behind. djs is behind on the shortest bodies, sequential and inspect, by a few hundredths of a millisecond: compiling the body costs about the same in both, and what is left is a handful of small builtin calls (Object.entries, toFixed), each dearer in djs (below). On ts djs compiles the TypeScript itself, while the other engines get JavaScript whose types the host stripped beforehand, outside the timing. monty is fast on heavy, whose string splitting and regular expressions are native in its Rust implementation, and slower on the rest; its times include the same JSON bridge in Python.

Memory

The instance’s linear memory after the run: what the run cost, since wasm memory does not shrink.

Linear memory after the run, MiB; the last row is the geometric mean of each engine’s over djs’s; measured at 1268c57eeb, 2026-11-06, load 2.3.

djs needs more memory than the QuickJS releases built here and less than quickjs-wasi, monty and the emscripten builds. Part of the gap is constant: the larger idle footprint above. The rest comes from the garbage collector. djs’s collector traces the live heap when the allocation since the last collection crosses a threshold, about as large again as what survived, so garbage stays until then; QuickJS counts references and frees most garbage the moment it is dropped. heavy, which allocates a few megabytes of short-lived lines and strings, shows it most.

Operation by operation

Single operations on data shaped like the workloads’, each in a loop, against the faster of the two QuickJS releases. Above 1, djs is slower.

Milliseconds per loop of the operation (js/bench/engines/ops.ts), the setup’s time subtracted; QuickJS: the faster of the two latest releases; measured at 1268c57eeb, 2026-11-06, load 2.0.

JSON, splitting and joining, regular expression matching, sorting strings, await and Promise.all are faster in djs. What is still slower is a group of small string and number builtins (trim, padStart, slice, toLowerCase, String(i), toFixed, Object.entries, Math.floor): djs writes most builtins in a TypeScript subset compiled to its own bytecode, and although the common ones take a fast path, a call still costs more instructions than a call of QuickJS’s C functions, which shows when the operation itself is tiny. sort with a comparator runs the comparator, a script function, for every comparison, and calling it from the sort still costs more than in QuickJS; Map.set and Set.add with string keys also take more instructions per call. These matter in a loop of tens of thousands of calls; in the workloads they are a small part of the time.

Passing data through the bridge

Moving data between the host and the sandbox is what cheap data passing is about: a tool result going in, a run’s result or a tool call’s arguments coming out. The workloads above pass every tool answer the same way in every engine, as JSON text, so that they compare the engines. This section instead compares the bridges: each engine gets the best path its embedding offers (js/bench/engines/bridge.ts).

Where an engine has two paths, each number below is the faster one’s: the handle walks of quickjs-wasi and quickjs-emscripten win on arrays of numbers, whose decimal text is slow to parse, and lose on most other values, and monty’s JSON text beats its value arena for anything larger than call arguments. The payloads: call arguments; a search tool’s result as an object, of 1 KB, 100 KB, 1 MB and 10 MB of JSON; source text of 1 MB and 10 MB (ASCII) and 1 MB of prose with accented letters, dashes and CJK; 100,000 floating-point numbers; a 1 MiB Uint8Array; and objects nested 100 deep (monty’s json.loads stops at about 200). Every value must read back equal to what went in. Each time is the median of one operation in fresh VMs; small payloads repeat within a sample.

In

Milliseconds per value put into a fresh VM (median), each engine’s best path; the last row is the geometric mean of each engine’s time over djs’s; measured at 1268c57eeb, 2026-11-06, load 2.0.

djs takes JSON-like values in about half the time of the fastest QuickJS path: a 1 MB search result in 3.1 ms against

format and the VM builds every object at its final size in one pass, where the others serialize it to JSON text on the host and parse that text again in the VM. A long ASCII string is one copy into a string the VM reserved for it (1.0 ms for 10 MB, against 3.8 ms for QuickJS, which first encodes the text into its linear memory and then copies it into a string). Text with non-ASCII characters gains less: it is encoded to UTF-8 and transcoded back in the VM. Numbers gain as much, since the wire format carries them as binary values instead of decimal text to be parsed.

Bytes are where djs is behind: a Uint8Array is copied into the encoder’s buffer, then into the staging buffer, then into the VM’s own bytes, three copies where the others make two. The emscripten builds pay the most for strings, because their glue encodes them to UTF-8 in JavaScript, byte by byte.

Out

Milliseconds per value read out of a VM (median), each engine’s best path; the last row is the geometric mean of each engine’s time over djs’s; measured at 1268c57eeb, 2026-11-06, load 2.0.

Reading out is where the designs differ most. djs’s reader decodes the value straight out of the VM’s memory, and the VM does no work at all; everyone else first has the VM write the value as JSON text, copies the text out and parses it on the host. A 1 MB search result comes out of djs in 1.23 ms, against

json.dumps is the fastest of the JSON paths here. A string comes out at the speed of a memory copy, since its characters are already in the form a host string needs. A Uint8Array is copied out in all of them; the reader’s copy costs a few hundredths of a millisecond more than reading the bytes in place by a pointer.

Throughput and memory

MB per second: the payload’s size over the median time; measured at 1268c57eeb, 2026-11-06, load 2.0.

Linear memory, MiB: of a fresh VM, after putting the value in, and after reading it back out; measured at 1268c57eeb, 2026-11-06, load 2.0.

The memory after putting a 10 MB value in is mostly the value itself in each engine’s representation. djs keeps a little more than QuickJS for JSON: its staging buffer stays as large as the largest wire encoding it was given. Reading the value out adds nothing in djs, while the engines that go through JSON text need room for the text, which in the emscripten builds doubles their memory. A 10 MB ASCII string takes about its own size in djs, one copy; in QuickJS it is there twice, as the UTF-8 the host wrote and as the string.

End to end

Three whole runs, each in a fresh VM, with a host function tool that every engine calls synchronously: a 1 MB search result of which the script returns one path, a 1 MB file that the script edits with one replace and passes to a second call, and a thousand calls with small arguments and results.

Milliseconds per run in a fresh VM (median): compiling and running the script, its tool calls through each engine’s host function; measured at 1268c57eeb, 2026-11-06, load 2.0.

The case of a 1 MB result of which the script reads one field is decided by putting the result in: every engine, djs included, builds the whole value before the script runs, so djs’s lead is that of the table above, and reading one string out costs nothing anywhere. Editing a 1 MB file shows both directions: the file goes in as one copy, and the edited text comes out to the second call through the reader, in

write the megabyte as JSON text inside the VM and parse it again on the host.

A thousand small calls are where djs is behind the minimal C embedding:

cheap everywhere, and what remains is the call itself: djs’s run returns to the host at every call, the host reads the call’s record, puts the result in and runs the VM again, while the C embedding calls the host function from inside the interpreter (the other QuickJS builds do too, but every value crosses through their JavaScript glue, and they are slower than djs). monty stops and resumes its run for every call, which costs it 20 ms.

In short, djs’s two halves pay off differently. The wire format makes the way in about twice as fast as JSON text for structured data and a single copy for long ASCII strings. The reader makes the way out an order of magnitude faster, because no engine work and no text happen in between. Bytes coming in and many tiny calls are the places where the simpler paths of the C embedding are still ahead.

Dumps

djs can write a run that waits on tool calls as a continuation dump and continue it later in a new sandbox. Here every workload runs through the sandbox with asynchronous host tools and is dumped at every idle point, every time it waits on a call:

Medians over a workload’s idle points; load: a new sandbox with the run loaded; measured at 1268c57eeb, 2026-11-06, load 2.3.

Most dumps are a few kilobytes, and gzip takes the larger ones to between a fifth and a third; they hold the run’s live state, so a dump taken while json holds 600 query rows, or while fanout holds the file texts it has read, is as large as that data. Writing one and loading it into a new sandbox takes about as long as starting a VM and running a small body; the json dumps take longest, as they encode and decode the most objects. inspect makes no tool call, so it never waits and has nothing to dump.

Re-running

scripts/bench-engines.sh          # fetch and build the engines, run, print the tables
scripts/bench-engines.sh --setup  # fetch and build only
scripts/status.py engines         # three runs; record the medians for this page
scripts/status.py bridge          # only the bridge benchmark
cargo run -q -p djs-docs -- regen # rewrite the tables

The engines go into vendor/engines of the primary checkout: npm packages pinned with their integrity hashes by js/bench/engines/package-lock.json, wasi-sdk and the QuickJS release sources pinned by SHA-256 in scripts/bench-engines.sh. Run it on a quiet machine: the harness prints the load it started at, and recorded numbers should come from a load below about 4.

Where to look

• js/bench/engines/run.ts: the harness, what it times and how
• js/bench/engines/engines.ts: each engine behind one interface, with its paths in and out for the bridge benchmark
• js/bench/engines/bridge.ts: the bridge benchmark, its payloads and end-to-end cases; driver.c: the C embedding of the two QuickJS releases
• js/bench/engines/prelude.js, prelude.py: the stub tools inside the engines
• tests/bench/codemode/: the workloads, their Python translations and tools.ts, the invented tool data
• scripts/bench-engines.sh: fetching and building the engines