jvq 0.6.0 adds a second way to measure. Instead of timing the benchmark, the new instructions adapter runs it under valgrind’s cachegrind and counts what it executes. A count hardly moves between runs and ignores how busy the machine is, so the budget drops from 5% to 1%.
On a shared 2-core VM, a real 2% slowdown passed the time gate as noise and came out at +1.9% counted, caught in 5 rounds. In the recorded scenarios, every 2% step was caught, every 0.5% step passed, and a no-change run never failed, beside a noisy neighbour too.
The review before release found the catch: a Go program with goroutines counted anywhere from 0.66 to 23.7 billion instructions, because Go’s idle threads spin under valgrind. jvq now runs counted commands with GOMAXPROCS=1, which brought that program to 215.0 to 215.1 million every time. It follows https://softdevstudio.com/jvq-keeps-a-history-of-every-run/.