Studio · experiment
Tests under the floor: why the suite is slow, and what is actually wrong
When pytest takes minutes on many cores and far longer serial — is that a large suite, a process defect, or tests written in a shape that cannot be fast?
Serial (FIND-1875)
2830 s@30f86071FIND-1875 era · Alloy measurement sitting
Serial (−n0)
1655 s@ab64c742Amber sitting · serial −n0 with durations file
Parallel (−n auto)
340.9 s@b4482a2eAmber sitting · shipped −n auto (Chert: 12 workers on that host)
1. What the account is
A live library arc handed as a session goal. It keeps wrong turns in so nobody re-walks them. The house rule on the page: a number carries the commit it was measured at; a sentence without a number is a claim.
2. What was already known
FIND-1875 recorded a serial run at commit 30f86071: thousands of tests in 2830 seconds, with a flat ~0.5 s floor across most of the suite and migration/store setup as a measured cost. Later patches introduced a pristine-store seam and pinned parallel collection.
3. The wall on one sitting
On a parallel durations run, one canary module fixture showed up twice near 206 s setup each — xdist runs module fixtures per worker that draws from the file. The export frames the 206 s figure under load as a claim where it was not re-measured after the mechanism was understood. A PATCH-575 regression in that canary was mended in the same sitting.
4. Amber's wall-clock table
A later sitting published a small table: serial at ab64c742 in 1655 s, and the shipped parallel run at b4482a2e in 340.9 s, with duration files named beside each row. A Chert correction notes that bare -n auto on that host started 12 workers (physical cores), not 24.
5. Short answer as framed
The export's short answer names three sizes of cost: one bench fixture on the critical path, a remaining tail of integration-shaped benches in the default run, and a floor that is git-bound more than sqlite-bound after the seam. It does not conclude that tests are written improperly as a class.