Development record
The implement loop package's tests are bound by git subprocesses: the slowest, TestPollingWithoutAnAnswerNeverHoldsTheIssuePastOneLease, runs Drain 120 times (a 4-minute poll over four 2-hour leases, kept inside the 5-minute take-over margin on purpose) and took 67s plain on a loaded machine, 31s on a quieter one with 3.84s of its own CPU; the next three take about 20s each, and the package is the slowest in both of the ubuntu leg's passes (320-410s plain, 470-650s race on 2026-10-18), with none of its 500 tests parallel.
The implement loop package's tests are bound by git subprocesses: the slowest, TestPollingWithoutAnAnswerNeverHoldsTheIssuePastOneLease, runs Drain 120 times (a 4-minute poll over four 2-hour leases, kept inside the 5-minute take-over margin on purpose) and took 67s plain on a loaded machine, 31s on a quieter one with 3.84s of its own CPU; the next three take about 20s each, and the package is the slowest in both of the ubuntu leg's passes (320-410s plain, 470-650s race on 2026-10-18), with none of its 500 tests parallel.
Grounds
- pursued: the loop package's tests and every drain move spend about a quarter fewer git processes, so the ubuntu leg's race step shortens by a minute or more; a merge-group race step no shorter than before would show it wrong
Outcome
The grounds were shown wrong on the first two merge-group runs after both changes (#1099, #1100, 2026-10-18). The ubuntu leg's race step took 20.8 and 20.6 minutes, at the top of the 14 to 20.6 minutes it had taken before, not a minute shorter. Its package times summed to 4,293 and 4,243 CPU-seconds, against 4,254 at the slowest run before. The loop package took 635 and 621 seconds under race, inside its earlier 470 to 650. The cut in git processes stands where it was measured (one drain test, 1,107 to 830), but that one test overstated it: across the whole of the loop and claim packages a plain run made 126,334 git calls before and 119,327 after, 5.5% fewer, which on CI is below the difference between runners. The longer lever is iss-2610181757540736. The leg's remaining time is tracked in iss-2610181711260494.
Frontmatter
| id | iss-2610180545134593 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610180545134593-the-implement-loop-package-s-tests-are.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610181711260494The check job's macOS leg has little headroom before its 50-minute warning: across nine merge-group runs on 2026-10-18 it took 35.2, 36.5, 38.9, 42.3, 42.4, 43.0, 43.9, 49.4 and 44.8 minutes, and the run of #1099 came within 0.6 minutes of the warning. Nearly all of it is the one race-enabled pass over the whole module, 41.9 to 47.4 minutes in the last three; the plain-only guard step after it takes under a minute. The warning fires at 50 and the job ceiling is 60.
- iss-2610181757540736The check job's race passes are set by their total work: the macOS pass keeps a steady 2.80 to 2.85 of its runner's three test slots busy and the ubuntu one about 3.4 of four, so no reordering shortens them, and their slowest packages (internal/core/implement/loop, internal/surface/cli, internal/core/claim, about 46% of the macOS pass) spend most of it in git processes. A first cut, a default-branch name per claim operation and a batched view (#1099, #1100), took one drain test from 1,107 git processes to 830 but the whole of the loop and claim packages only from 126,334 to 119,327 (5.5%), which CI could not tell from the difference between runners; a cut measured on one test overstates the package.