How to benchmark a PDF/A validator
Every performance claim on this site is traceable to one dated run over one named corpus on one named machine. A benchmark without those three things cannot be checked by anyone, and a claim nobody can check is worth nothing.
Cold and batch measure different things
The most misleading choice in a validator benchmark is which of these you report. A batch run puts the whole corpus through one process, so fixed startup cost is amortised away and what is left is the verification engine. A cold run starts a process per file, so startup is paid every time, which is what a CI step or a per-request invocation experiences.
Measuring only one of them tells only half the story. That's why both are shown side by side on the benchmarks page.
Startup is also measured on its own, with no PDF read at all. This number determines whether validating on the request path is viable.
Ratios are the easiest place to cheat
A ratio has a numerator, a denominator and a metric, and changing any of the three changes the headline. On this site the ratios are computed from the recorded measurements at render time rather than written into the prose.
That is a small piece of engineering with a specific purpose. When the next benchmark round lands, the sentences update with the data instead of quietly keeping an old number.
Methodology
The corpus, the commit, the Go version, the machine and the tool versions each run was taken against are written out in full on the benchmarks page.
What the numbers do not say
The numbers say nothing about coverage. veraPDF validates PDF/A-2, -3, -4 and PDF/UA, and gopdfrab does not, so speed on the subset both implement settles no question about scope. The comparison is the place for that.
They say nothing about your documents either. The corpus consists of small conformance-test files. Real archives are larger and stranger, and absolute numbers will differ.
Finally, the numbers say nothing about correctness. That is what the conformance suites are for.