17:30 to 4:47. First, fix the comparison.
Serial and parallel runs reported the same totals. The first comparison still missed cases. Matching all 2,773 outcomes was the important part.
// 01
The attractive number
A 22 August 2026 build record reports two back-to-back test runs on the same committed tree. Serial: 17 minutes 30 seconds. Parallel: 4 minutes 47 seconds. Both reported 2,768 passes and five skips. That is about 3.65 times faster for this pair of runs.
// 02
The comparison agreed too easily
The first comparison split a test identifier at whitespace. Parameterized identifiers could contain spaces, so different cases collapsed into shared keys. It compared 2,701 keys while the runs contained 2,773 outcomes. Equal counts were not enough: two runs could pass different parameters and still appear to agree. The comparison was changed to preserve complete result lines, including multiplicity. The record then reports an exact match across all 2,773 outcomes.
// 03
Keep the result the size it actually is
This is a write-up of the recorded comparison, not a fresh benchmark or an independent reinspection of its raw outputs. It supports one matched pair, not a general claim that the development pipeline is 3.65 times more productive. Parallel execution stayed an explicit development option: a host without the required plugin rejected that command. A faster local run was no reason to break the ordinary test command elsewhere.