Workshop · floor model for Survey of Software 1.056

JSONic rituals

The 6× is a serialising number. orjson writes JSON five to ten times faster than the standard library — and reads it back about twice as fast. The fastest reader on this page is the one that also checks the shape of what it read.

Paste your own JSON below. It never leaves this tab: the libraries run here, in your browser, and the numbers are about your data.

Plain language. Switch to Engineering for versions, byte counts and the measurements behind each claim.

The whole answer, first

Two rituals: dumps turns your objects into JSON; loads turns JSON back into objects. The fast libraries are very fast at the first and only somewhat fast at the second — and the second is the one most programs do more of.

Serialisation is where orjson and msgspec separate from the standard library (5–10× on realistic documents); parsing is 1.5–2.5×. A typed decoder — msgspec with a Struct — is the fastest parser measured and validates on the way in; the schema is the price and the point.

dumps — object → JSON

5–10×
orjson or msgspec over the standard library

loads — JSON → object

1.5–2.5×
orjson or msgspec; a typed msgspec decoder at the top

Use orjson if serialising dominates and you can take bytes back. Use msgspec if your data has a shape — it reads fastest, validates free, and its Structs hold half the memory of dicts. Keep the standard library if neither is measurably on your path; ujson buys ~1.2× now, and python-rapidjson buys less than nothing.

The rule of this page: every figure below is measured on your machine while you wait, by the Python libraries themselves running in this tab. Where a number came from research instead, it says so in orange.

What to measure

Your own JSON — paste it, then click outside the box (or choose a file, first 1 MB)

Press start to download CPython 3.14 (WebAssembly). First time only, then cached.

Your data, both rituals

Each library, writing your JSON and reading it back. Bars are multiples of the standard library; longer is faster.

Best-of timing under a budget; batches calibrated to ≥5 ms because browser clocks clamp at 100 µs. Multiples are against json from the 3.14 standard library in this same tab. Round trip verified for every untyped decoder.

Waiting for start.

dumps — object → JSON

loads — JSON → object

msgspec — why parse into dicts at all

The fastest row above needed a shape to aim at. This page guessed one from your JSON — here it is, and here is what it costs when the data does not fit.

A msgspec.Struct inferred from the first object: primitives by type, nested objects as nested Structs, lists by their first element. Good enough to measure; you would write the real one. Validation is the point: the typed decoder rejects a wrong shape at parse time with a path, and holds about half the memory of the equivalent dicts.

Waiting for start.

What could not be measured here

From research, not measured in this tab

python-rapidjson is not in Pyodide. Native, one machine (CPython 3.14.7, aarch64): slower than the standard library on every sample — loads at 0.80× stdlib on the logs, 0.83× on the nested config, 0.83× on the numbers — confirming the survey's caution and sharpening it from "sometimes" to "every time measured". 4.7M downloads a month.

Memory. Resident memory after loads of a 19 MB numeric document: stdlib 106 MB, orjson 104 MB, msgspec 100 MB — the dicts are the dicts, whichever library built them. msgspec Structs: 47 MB (2.2× less), 40 MB with gc=False. pydantic models: 436 MB. orjson adds a transient ~75 MB peak while parsing. The survey's "6–9× less memory" is 2.2–2.6× resident, typed against untyped.

Across interpreters (3.11, 3.12 and 3.14, same machine): orjson reads 1.6–2.1× stdlib and writes 5–13×; ujson 1.1–1.7× reading, 1.2–2.7× writing. None of it is a Python 3.14 effect. The survey has the workings.

Start your build

Take what you just measured and hand it to whichever AI you use — your sample, your numbers, the schema this page guessed, and a brief for what to do next.

Clipboard envelope — no vendor deep link, no API key, no dependency on anyone's roadmap.

Run the page first.

Open the lab

This page is the result. The method is a notebook you can open and change — the same samples, the same timing, the same schema inference, as cells: open it in marimo (runs in your browser, nothing installed), or run it on your machine:

uvx marimo edit https://research.modelcitizendeveloper.com/workshop/jsonic-rituals/jsonic.py

jsonic.py imports core.py — the measurement this page runs, one file, no copies — with marimo's UI instead of this page's.

This floor model was first built as that notebook and exported with marimo export html-wasm. The export worked — paste, file, register switch, clipboard (through a sandboxed iframe; marimo strips inline handlers) — and measured 9.8 s to first number against this page's 2.6 s, 22 MB against 8 MB, on the same machine with a cold cache. Its kernel is Python running inside Pyodide, so the gap is structural, and a 29 MB hashed asset bundle per marimo version is not something to commit to a Pages site. So: the notebook is the lab, the page is the floor model, and the lab is opened where marimo hosts it. The verdict and the criteria are in the Report.

JSONic rituals is a floor model for Survey of Software 1.056 — JSON Libraries, verified 2026-08-19. Libraries run under Pyodide (CPython 3.14 compiled to WebAssembly) in this tab; nothing is sent anywhere. Throughput here is WebAssembly throughput — roughly half of native, same shape. Measurements are from your machine except where marked orange.

Made by Ivan Schneider · Model Citizen Developer