The benchmarks page is a table of results. This is the reasoning underneath it: what actually goes wrong with a Usenet post and why it costs time, how we run a round and what makes a result count, and what each column we publish is really measuring. Written for people who want to check our thinking rather than take the numbers on trust.
One
The architecture the rest of the site keeps referring to. What happens to the bytes, why it is a different thing from direct unpack, which archive shapes survive it, and what removing the write-and-read-back cycle is worth in disk, processor time and memory.
Two
Posts arrive with holes in them more often than people expect, and that is where clients differ most. What a missing article is, why asking for one is expensive, and why the fix is to stop asking rather than to ask faster.
Three
The machines, the fixtures, the settings each client gets, and the rules that decide whether a leg counts at all. Includes the checks that exist because we got something wrong once and would rather not repeat it.
Four
Time to a usable file, peak memory, processor seconds, peak disk, volume I/O. What each one is, why we publish it, and what a good or bad value actually looks like on a machine you own.
And the raw data
Every measured result lives on the benchmarks page, with the build and the date beside each table, including the legs we lose. These pages explain it; that page is the evidence.