Measured, not promised

What exactly is being measured

Each row times the pure function that does the work: the parser, the formatter, the diff algorithm, the hash. It does not time the browser, the DOM update, the paint or the time it takes you to move the mouse. That is deliberate. The algorithm is the part that would be slow if the implementation were bad, and it is the only part that can be compared across machines without also comparing screens, extensions and power settings.

The measurement is the median of nine runs after one warm-up run. The warm-up matters: without it, the first call absorbs the cost of compiling the function and allocating its data structures, and a nine-run median would mostly report that. The best run is published next to the median because the gap between the two is the honest measure of how noisy the machine was.

Why the inputs are generated, not chosen

Every input is produced by a function in the benchmark script, at a fixed size, with the same content on every run. A hand-picked input is a benchmark that can be tuned until it flatters the code; a generated one cannot. The sizes are chosen to be realistic rather than impressive: one megabyte of JSON is a large payload you might actually paste, ten thousand CSV rows is a real export, two thousand diff lines is a real file.

What the numbers do not tell you

• Your machine is not this machine. A phone will be several times slower and a browser's JavaScript engine differs from Node's. The relative order between two operations is more stable than the absolute numbers.
• It does not measure the network. There is no network step to measure: the tools do not call a server. That absence is the point, and it is why the column of round trips is zero.
• It is one run of the script, not a distribution. There is no confidence interval and no p-value. A benchmark page that pretends to statistics is usually a benchmark page hiding something.

How to reproduce it

The script is in the repository as scripts/bench.ts, and it writes the same src/data/benchmarks.json that this page reads. Run it with npm run bench. It prints a table and rewrites the file, so a change to an algorithm that makes it slower shows up in the diff of the next commit.

That last property is the reason the page exists. A performance claim in a README rots the moment somebody edits the parser. A number that is generated by a script and committed alongside the code cannot rot quietly.

Why this matters for a tool that runs locally

When a tool runs on a server, the user cannot tell a slow algorithm from a slow connection, and nobody has an incentive to find out. When it runs in the browser, the latency is yours: every millisecond of a bad algorithm is a millisecond the person waits with the tab frozen. Publishing the number is a way of saying that the difference between 3 µs and 102 ms is a decision somebody made, not an accident.

The tools that sit at the slow end are the ones that do the most work per byte. The text diff walks two thousand lines and then diffs the words inside every changed line; JSON Repair runs a dozen recovery passes because a document can be broken in a dozen different ways. Both are still under a tenth of a second, which is the threshold where an interface stops feeling instant.