Benchmark

JSON against jalapenojson: the same rows, read and written by each, in JavaScript, Python, C and WebAssembly. Every table has the same shape: JSON in one column, jalapenojson in the next, and how many times faster or slower jalapenojson is.

Measured on 2026-10-03 at commit 2eb975b: Intel Xeon Processor @ 2.10GHz, 4 cores, Linux 6.18.44-fc-v64; Node 24.21.0, Python 3.11.15, cc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 with -O2, cJSON 1.7.19, yyjson 0.13.0. Reproduce with bench/run.sh.

The data

Two sets of rows with the same seven columns: id (i), user, city and plan (s), seats (i), price (f) and joined (d). They are never averaged, because they disagree about size.

• repetitive is the shape API output usually has: a user drawn from two thousand, a city from eight (one of them Tromsø, so the text is not pure ASCII), a plan from four, a price from a price list.
• high-entropy fills the same columns with random letters and numbers, so there is little for a compressor to find in either format.
• nested orders, orders carrying one to six line items each, is measured for size only.

bench/data.mjs writes each set once, as JSON and as jalapenojson, and every language reads those same files.

Size

Raw, then compressed the way a server would send it: gzip at level 6, brotli at quality 5 (compressed as it is sent) and 11 (compressed once, ahead of time).

JavaScript

JSON.parse and JSON.stringify against decode(), view() and encode(), on Node 24.21.0. Warmed up: the fastest run once the reader has run for 200 ms, which is what a server or a page that reads many documents sees.

• read every value builds every row as an object: JSON.parse against decode().
• read every value, as columns ends with one array per column: JSON.parse and a pass per column, against view() and column().
• read one number column, read one text column and read one row end with the values of price, of city, or of the middle row: JSON.parse and a pass, against view() and column() or row().
• write every value turns the rows each reader built back into bytes: JSON.stringify and a TextEncoder, against encode().

JSON's time includes turning the bytes into the string JSON.parse takes, because jalapenojson's includes reading the same bytes. Handed a string it already has, JSON.parse alone takes 20.9 ms on the repetitive rows and 26.8 ms on the high-entropy rows at 50,000 rows.

The first call

A page that reads one document reads it once, in a process that has never run the reader: V8 compiles a JavaScript reader as it goes, while JSON.parse is already machine code. Each number is the median of one run in each of several fresh processes.

1,000 rows

In a browser

Everything above starts with the bytes in memory. A page has to receive them first. Chromium 141.0.7390.37, driven by Playwright, fetches each document from a local server that sends it gzipped, over a connection DevTools slows to a given speed and latency, and then reads it: what a page that fetches one document waits for. The download is the fastest of three; the read is the first one a fresh page does, the median of several pages.

At 50,000 rows on fast 4G, reading every value is 4% with JSON and 7% with jalapenojson on the repetitive rows, and 2% with JSON and 2% with jalapenojson on the high-entropy rows, of what the page waits for. The rest is the download.

At 1,000 rows on fast 4G, reading every value is under 1% with JSON and 4% with jalapenojson on the repetitive rows, and under 1% with JSON and 3% with jalapenojson on the high-entropy rows, of what the page waits for. The rest is the download.

Python

json.loads and json.dumps against decode(), view() and encode(), on Python 3.11.15. The same tasks, warmed up the same way. Python's json is written in C; jalapenojson's Python reader is Python. JSON is written compact and as UTF-8, the way the file it was read from was.

1,000 rows

C

cJSON, the library most C code uses, and yyjson, one of the fastest JSON parsers there is, against jj_parse() and the accessors. Each run parses and then reads what the task asks for: a number as a double, checked against its grammar as the JSON parsers check it, and text as a pointer and a length. There is no C encoder, so there is no write task.

1,000 rows

WebAssembly

jalapenojson's C reader compiled to WebAssembly. Ubuntu clang version 18.1.3 (1ubuntu1) built jalapenojson.h for wasm32-wasi with -O2, against wasi-libc, into a module of 34 KB, 13 KB gzipped. Two questions, measured apart: whether reading through it is faster than the JavaScript reader, and whether jalapenojson's lead over the JSON parsers survives the move to WebAssembly.

WebAssembly cannot make a JavaScript string or object, so bench/wasm.c converts each number and copies each text value into one run of bytes in the module's memory, and bench/wasm.mjs turns what it leaves into the values the JavaScript reader hands back: the run of text is decoded once and each value cut out of it, and the rows are built in JavaScript. Every call copies the document into the module's memory first, because that is the only memory WebAssembly reads, and the copy is timed. The tasks are the JavaScript section's, but for writing, on Node 24.21.0, warmed up the same way.

The first call

One run in a fresh process, the median of several, as for the JavaScript reader. The module is compiled and instantiated before the clock starts, as the JavaScript reader is imported before it starts, so what a first call pays for is what V8 compiles as it goes, in either.

In a browser

The first read in a fresh page of Chromium 141.0.7390.37, the median of several pages, as in the browser section. The document is the one the JavaScript reader reads, so it downloads in the same time, and only the read is shown. Fetching, compiling and instantiating the module took 3.23 ms in a fresh page, the median over those pages, which a page does once and can do while the document downloads.

Inside WebAssembly

The C section's measurement compiled whole: bench/c.c, with cJSON and yyjson, built for wasm32-wasi the same way and run by Node's WASI. Numbers and text stay inside the module, as they stay inside the process in C, so nothing crosses into JavaScript, and this is WebAssembly's own speed.

Against the same code built natively, in the C section, a run in WebAssembly takes this many times as long at 50,000 rows: 0.7x to 1.0x with cJSON, 1.2x to 1.4x with yyjson, and 1.0x to 3.2x with jalapenojson.

1,000 rows

How it was measured

• Each number comes from its own process, started for that one measurement, so no reader runs in a process another reader has warmed.
• Warmed up means the task ran until it had run for 200 ms, and then the fastest of at least 15 more runs and at least 500 ms was kept. The number shown is the median of that over 5 rounds, each of which ran every measurement once, in a different order.
• Every run's result is checked: a count of the values it read, their sum, and a CRC-32 of their text, against the same worked out from the rows the files were written from. A run that read something else stops the benchmark.
• The input is bytes in memory for both formats. Freeing memory is not timed in C; in JavaScript and Python the garbage collector runs when it runs.
• In JavaScript and Python jalapenojson checks every date it reads, and Python gets date objects; JSON has no dates, so its readers hand the same values back as unchecked strings. In C every reader hands a date back as text, and so does the WebAssembly reader, having checked it.
• The WebAssembly modules are built by bench/run.sh on every run, from bench/wasm.c and bench/c.c, and are measured by the same workers and checked against the same checksums as everything else.