Survey of Software · the workshop
Free working instruments that measure a survey's finding on your data. Most run in your browser — the real Python libraries run in the tab, nothing is uploaded, and every figure is measured while you wait or marked in orange when it came from research instead.
Some cannot. A compiled tool — Ruff, Biome, a Rust binary — will never run in a tab. Those ship as a container you download and run, pinned end to end, with the recipe published so the numbers are checkable rather than trusted.
Each of these exists because building it verified the survey it demonstrates: every claim became code that had to run, and what the code contradicted, the survey corrected. The page is the instrument; the survey has the workings.
A project needs a formatter, linter, type checker, parser and test runner — five tools that all read your source. Answer six questions and this picks a set and names the runner-up. Most people arrive asking which is fastest; on a 1 MB codebase the measured gap is 0.014s against 0.40s — a real 28× that nobody can feel. What decides it is whether your rules can be somebody else's rules, and whether a tool's cost grows faster than your codebase does. Pylint's does: 12× more code costs it 23.5× more time — a shape that reproduced on two architectures — where Biome's costs 3.8×.
Ruff's README claims 10-100× faster than Black. Measured on a clean x86 machine, it is 16×. The ARM cells read higher but came from a busy laptop, so whether the ratio depends on architecture is still open. Biome's “25× over Prettier” is wrong on a small codebase and right on a large one, so that claim's defect is the workload it never states.
Kill a running job with a button labeled Deploy and watch one lane pay for the same work twice. It runs a real photo-ingestion pipeline — read the EXIF, thumbnail, downscale, then tag and caption each shot — on photos from your own machine, and prices the vision call it never makes: shrinking the image first saves 43% on one model tier and nothing at all on the other.
FastAPI is Starlette plus a layer, and the layer costs 3.9×
the framework it sits on. The usual explanation for that cost is the validation; it is 4%
of it — and checking a message is faster than reading it without checking, because
pydantic replaces the parser instead of sitting on top of it. Race them in your tab, then
paste your own JSON.
A cache is paid for by its misses. The standard library's lru_cache answers
a hit in 0.03 µs; cachetools in 0.5; diskcache in 4 — and then charges 350 µs for the write after a
miss, so a 100 µs function needs 82% hits to break even. Pick your traffic's shape: LRU scores 0% on
a loop, at any size up to half.
Keep 100,000 keys in order, one insert at a time: pure-Python
sortedcontainers beats the standard library's C by ten times — and if you only
needed the order at the end, or just the minimum, the standard library beats it back. A race
you start, with bars arriving in finishing order.
The famous "orjson is 6× faster" is a writing number — reading is
about 2×, and the fastest reader is the one that validates. Paste your own JSON: both rituals
are timed on it, and the page infers a msgspec.Struct from your data and shows
what validation catches.
One answer for the whole speed-versus-size range except the two far ends — and the read-back speed does not move whichever level wrote the file. Drop your own file on the full curve: every codec, every setting, each library's default ringed.
"You can cover 30% of a QR code" is off by roughly three times. Grow a logo through the middle of your own code until it breaks, then point your phone at the screen — the camera you own is the second instrument.
Sorting is solved. Choosing how to sort is not — the real sorting libraries raced on your machine, and which one wins depends on your data's shape and size.
Each page downloads CPython compiled to WebAssembly (Pyodide) the first time — a few seconds, then cached — and runs the actual libraries from PyPI in your tab. Your file, your JSON, your payload never leave your machine. A Plain / Engineering switch shows the same demonstrations in ordinary words or with versions, byte counts and the measurement behind each claim; every page ends by copying a brief — your settings, your measured numbers — that you can paste into whichever AI you use to build the real thing.
The shared runtime is
/workshop/_lib/; each page's measurement is one
core.py beside it, fetched by the page and imported by the survey's native bench —
the same code both places. Timing is best-of under a budget, batch-calibrated past the browser's
clock clamp.
The Workshop is part of Survey of Software — neutral, category-first research on software libraries. Each floor model links its survey; each survey's S2 has the measured tables and the record of what building the page corrected.
Made by Ivan Schneider · Model Citizen Developer