For developers
The build is slow. Is it the code or the cooling?
Compiles and test suites load every core for minutes and punish memory latency. SystemCheck measures both, repeatably, so a slow build can be blamed on the right thing.
What the report tells you
Three figures, each with its reading.
Sustained all-core
ops/s
One worker per logical core for the run's length. This is the figure a parallel build sees, not the single-core boost on the box.
Memory latency
ns
The round trip to memory and to cache. Linkers, package managers and anything pointer-heavy run at this speed.
Repeatability
%
Run the CPU stage twice and the report states the spread. A change inside the spread is not a change, whatever the build timer said.
The diagnosis
The shape of the curve, read for your case.
01Held
The machine is not the problem. Look at the build graph, the cache, and what else is running.
02A single step down
A power limit, most often the sustained wattage on a laptop. Long builds run at the level after the step, not before it.
03Erratic
Something else is on the cores. An indexer, a sync client, a container that never idles. The report's core-share figure names starvation when it can see it.
Every class comes with a stated confidence and the measurement’s own noise floor. How the shape is read
Where a browser stops
What it cannot tell you.
- No per-core clocks: the browser sees throughput, not frequency. The curve shows the effect of a clock change without naming the megahertz.
- No contention detection inside a run: a program that quietly shares the cores is indistinguishable from a slower machine. The before/after comparison is the instrument for that.
- Core count as reported: Firefox caps it, Safari caps it at eight, and the report says which count it used.
Which run
Standard, 3 minutes.
For a repeatable baseline the standard run, repeated, gives a spread quickly. Use the deep run once to find the settled level on a laptop.
Both kinds are free. The choice is on the set-up screen.
Questions
Asked in these words.
- Why is my build slower than the benchmark suggests?
- Build times reflect sustained all-core throughput and memory latency, not the single-core boost most benchmarks headline. The test reports both, and the curve shows whether the machine holds its all-core level for the length of a build or steps down after the boost window.
- Can I use this to compare two machines?
- Yes, on the measured figures: sustained throughput, decay, memory bandwidth and latency, frame time. Run each machine twice so the report can state the spread; a difference inside the spread is noise.
- Does Docker or a VM affect the result?
- Anything using the cores during the run lowers throughput and raises noise, and the report flags starved workers when it can see it. Quit what you can before a baseline, then run again with the usual load to measure the cost of it.