Skip to content

Find what still makes the macOS test shards slow after #857 #894

Open

Description

@JacobStephens2

This was generated by AI during triage.

After #857, the macOS shards still spend 65-70 minutes of test time per CI run. #857 removed 22% of process spawns in its benchmark test on Linux. The macOS saving on main has been smaller and within the ±15% run-to-run noise #857 itself measured:

Shards 1 / 2 / 3 / 4 test-step seconds Sum
main before #857, 39337614995 (from #857) 1107 / 1120 / 969 / 1191 4,387
main before #857, 39328254506 (from #857) 1193 / 937 / 1174 / 972 4,276
main after #857, 39424072554 1189 / 1063 / 959 / 1037 4,252
main after #857, 39424576921 1076 / 935 / 986 / 1019 4,020
main after #857, 39430050727 769 / 1099 / 1066 / 982 3,920

In 39430050727, nextest flagged 93 tests over 30 s and 16 over 60 s. By module: spec_run 47, architect_run 9, security_review 7, security_run 5, pickup_run 5, merge_run 5, base_fix 3, bin 3, then run_notification, codex_sessions, ci (2 each), and stop, show_logs, issue_number (1 each). Linux runs the whole suite in about 8.5 minutes.

#857's analysis came from strace on x86_64 Linux. No one has yet attributed the macOS time itself: how much is process spawn, how much is the launch-side --git-common-dir rechecks #858 holds, and how much is something else, such as fixed sleeps, real-time polling or timeouts in the test harness.

Related, not duplicated

Activity

  1. JacobStephens2 commented on Oct 20, 2026

    @JacobStephens2
    OwnerAuthor

    This was generated by AI during triage.

    Agent Brief

    Category: enhancement
    Summary: Attribute the remaining macOS test time and remove the causes that are not Worktree ownership rechecks

    Current behavior:
    After #857, the four macOS shards spend 3,900-4,250 seconds of test time per CI run, against about 8.5 minutes for the whole suite on Linux. 93 tests run over 30 seconds on macOS, 47 of them in spec_run. The only profile so far was taken on Linux, and it pointed at Worktree ownership inspection's git spawns.

    Desired behavior:

    1. Attribute. For the slowest macOS tests (at least the 16 over 60 seconds and a sample of the spec_run ones), measure where the wall time goes on macOS: spawned processes by program and caller, time spent in fixed sleeps, polling intervals or timeouts, and anything else that dominates. Use a macOS runner, a workflow_dispatch job, or a temporary diagnostic step in a PR. Record the method and numbers in docs/ci-performance.md under "Where macOS test time goes".
    2. Fix what is in bounds. Remove or shorten causes that don't touch Worktree ownership checks. Examples: test-only waits that could be event-driven or configurable, test fakes that cost more than they need to, repeated setup a test could share, and production intervals that tests should be able to set shorter. Each change keeps what the test asserts.
    3. Hand back what isn't. If the attribution shows the launch-side repository rechecks dominate, add the macOS numbers to Decide whether Worktree ownership inspection may recheck the launch repository less often #858 as a comment, and leave the decision there.

    Key interfaces:

    • The integration test harness: the fakes for gh, claude and codex built from the test fakes, and the helpers that start the binary against real git.
    • Any interval or timeout the factory waits on in tests, such as CI watch polling and the waiting line, and how a test sets it.
    • Directory::verify_repository and Worktree ownership inspection are read-only for this issue.

    Acceptance criteria:

    Out of scope:

  2. added
    ready-for-agentFully specified, ready for an AFK agent
    in-progressA Claim: thirdshift has taken this issue
    and removed
    ready-for-agentFully specified, ready for an AFK agent
    on Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestin-progressA Claim: thirdshift has taken this issue

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions