perf(test): cut cant-fail-scan.test.sh's Windows wall clock (891 s against 128 s on Linux)

Parent: #3716 (criteria 3 and 4). Measured in #10241, docs/test-wall-clock-baseline.md.

Problem

plugins/testing/skills/audit/scripts/cant-fail-scan.test.sh took 891 s on the Windows Git Bash host in #10241's corpus run, against 128 s on Linux CI: 7 times slower, and on its own past the 10-minute budget for the whole Windows corpus.

Fix

Profile the suite and cant-fail-scan with scripts/run-plugin-tests.sh's timing option (#10200) and a spawn count. Cut the spawns the way #3716 step 3 lists: builtins over subprocesses, one batched call over many, hoisted walks, shared fixtures. The suites must pass unchanged, so behavior is preserved.

Done when

Linux wall clock for the suite, before and after, is in the PR body
The Windows time, re-measured on a Windows Git Bash host, is in the PR body and in the suite's row in docs/test-wall-clock-baseline.md
The suite's assertions are unchanged (any test edit is a fixture or harness change, named in the PR body)
ci-status is green on the PR head

Split by the backlog HITL session from #10241's result. This was generated by AI.

Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.

Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none

Decision recorded. Route this issue to the host queue whole, for a laptop lane with a Windows Git Bash host.
Agent choice, not an owner answer.

Admission refused it for the lane because Done-when item 2 needs a Windows Git Bash host, and a child issue for that one step would raise the open count, so the issue goes host-run instead. The spawn cuts and the Linux before/after can be built and measured on Linux; only the Windows re-measure needs the Windows host, so one host session does the whole change in one PR. The body's Done-when stands unchanged.

On a fleet host with Windows Git Bash, re-measure the suite before and after the change and record both times in the PR body and in the suite's row in docs/test-wall-clock-baseline.md.

#13231 (comment)

This decision settles the open routing question, so no further questions are open. I understood the issue as cutting process spawns in cant-fail-scan.test.sh, with unchanged assertions, so its Windows wall clock drops. The Windows re-measure is host work, not a reason to hold the issue. No duplicates found; the sibling perf issues #13229 and #13232 cover other suites.

_{Automated triage, applied by the lanes App.}

Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 2 (measure-over-time: "The Windows time, re-measured on a Windows Git Bash host, is in the PR body a..."), item 5 (a run on a host the lane is not: "On a fleet host with Windows Git Bash, re-measure the suite before and after ..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (host-run); it carries host-run. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).

The latest triage verdict holds nothing: admission moved the issue to status: confirmed; its comment says why.

No description provided.

perf(testing): keep the walk's error log beside WALK_ERR, not in a ne…

No description provided.

Measured, not shipped: one tree walk per run does not cut this suite's Windows time. Branch perf/13231-cant-fail-scan-windows-wall-clock (bbe5eba, pushed, no PR) walks the tree once per scan instead of once per pass (up to 7 find and sort pairs) and picks each file's adapter without a subshell. All 1,395 checks pass, and six old-versus-new scans of real trees, the whole repository included, produce identical output.

Measure	Before	After
Windows Git Bash, paired runs alternated, nothing else of this lane running (s)	772, 785	788, 699
Linux, suite, three alternated pairs (s)	139.5, 126.6, 168.8	110.4, 130.4, 121.6
Linux, whole-repo `--count` scan, three alternated pairs, load about 25 (s)	43.0, 41.3, 41.1	45.0, 42.9, 41.4
Process starts per suite run, `strace -f` (Linux)	57,037	47,133

The two Windows pairs overlap, so no gain is established. On a full tree, the name filter that replaces the separate walks runs in a bash loop, which makes the production scan no faster and possibly slightly slower. An earlier Windows run (961 s) overlapped other work on this host and is not used.

Per-launch cost on this Git Bash host (50 runs each; Windows 11, Git for Windows 2.56):

Launch	ms
`$(:)` subshell	10
pipeline `: \| :`	16
`/usr/bin/true`	18
`dirname`, `grep`, `sed`, `find`, `awk`	19-24
`bash -c :`	30
`git rev-parse`	32
`sort` (in a pipe)	33
`tr` (in a pipe)	36
`mktemp`	44
`xargs`	54

Multiplying the trace's counts by these costs predicts more time than the suite takes, so the counts are not yet a reliable attribution. Before the next cut:

Attribute process starts and forks to their nearest parent (the suite, cant-fail-scan.sh, or an awk engine) from the trace's pid tree, then multiply by the costs above.
Cut the largest bucket that stays behavior-preserving, and measure it with paired Windows runs.

The issue stays open and unclaimed for that work. The branch is kept for reference and can be deleted.

Posted by host-run Lane 5. This was generated by AI.

No description provided.

docs(testing): record cant-fail-scan.test.sh's Windows time after the…

Navigation Menu

Repository navigation

perf(test): cut cant-fail-scan.test.sh's Windows wall clock (891 s against 128 s on Linux) #13231

Problem

Fix

Done when

4 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

perf(test): cut cant-fail-scan.test.sh's Windows wall clock (891 s against 128 s on Linux) #13231

Description

Problem

Fix

Done when

Activity

github-actions commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

4 remaining items

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions