Development record
recordid's filename grammar compiles a fresh regexp on every call: idRe (behind FilenameNumRe) runs regexp.MustCompile each time, and both per-file readers call it once per record file, the resolver's fileID in internal/core/recordid/resolve.go and peers' fileID in internal/core/peers/read.go. Every resolver scan and every peers scan, which the bare board runs on each render, therefore recompiles the same pattern once per record in the checkout: 29% of the CPU of the bare-board tests in internal/surface/cli, and several times that under -race, where it inflates the macOS check leg that iss-2609261924541555 records running past the merge queue's cap. The grammar is a pure function of a fixed family prefix, so one compiled pattern per prefix answers identically.
recordid's filename grammar compiles a fresh regexp on every call: idRe (behind FilenameNumRe) runs regexp.MustCompile each time, and both per-file readers call it once per record file, the resolver's fileID in internal/core/recordid/resolve.go and peers' fileID in internal/core/peers/read.go. Every resolver scan and every peers scan, which the bare board runs on each render, therefore recompiles the same pattern once per record in the checkout: 29% of the CPU of the bare-board tests in internal/surface/cli, and several times that under -race, where it inflates the macOS check leg that iss-2609261924541555 records running past the merge queue's cap. The grammar is a pure function of a fixed family prefix, so one compiled pattern per prefix answers identically.
Grounds
- pursued: every resolver and peers scan reads the grammar once per record file without compiling it; FilenameNumRe returning a distinct pattern per call, or fileID allocating more than 8 times per id, would show it wrong.
Frontmatter
| id | iss-2609261943168303 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609261943168303-recordid-s-filename-grammar-compiles-a.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609261924541555The macOS check job exceeds the merge queue's 30-minute cap once the cli lane's worked-example tests land: on PR #728 (integration head d850f06f) run 36262653588 was cancelled at 30.3 minutes while internal/surface/cli was still running under the race lane, where main's macOS runs take 23 to 28.5 minutes. The job's timeout-minutes equals the queue's check_response_timeout, so the queue fails the group rather than waiting. The cli package's test wall time, above all under -race, is the lever: it must come down by at least the three minutes the leg is over without weakening what the tests prove.