Skip to content

fix: lifecycle performance cliffs in change check/list/correct-owner (closes #439)#463

Draft
0xLeif wants to merge 1 commit into
mainfrom
fix/439-lifecycle-perf
Draft

fix: lifecycle performance cliffs in change check/list/correct-owner (closes #439)#463
0xLeif wants to merge 1 commit into
mainfrom
fix/439-lifecycle-perf

Conversation

@0xLeif

@0xLeif 0xLeif commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

⚠️ Status note

This PR currently contains 1 of 2 changed files. src/change.rs (860KB) could not be uploaded through the automation channel — the complete 31KB patch (w6-439.patch, applies cleanly on main @ ce66973, commit 73ad0d1) is attached to the task report. The branch will not compile until the change.rs portion lands.

Problem

Lifecycle commands degraded superlinearly at modest scale: change check hit double-digit seconds at 20 changes, change list/status cost ~190 ms per change, and change correct-owner batches revalidated every correction after each appended entry (O(entries^2) Git-backed ownership lookups).

Root causes

  • Read-only lifecycle surfaces repeated repository-global Git lookups and the full (doubled) Git evidence pipeline for every change, and terminal-evidence validation recursed over accepted chains with a fresh memo per change — thousands of git subprocess spawns at 20–50 changes.
  • correct-owner batches re-validated all pre-existing corrections after every appended entry, each with its own canonical-spec evidence collection.

Fix

  • Read-only commands (list/status/show/check) now run in a scoped per-command memoization scope: repository-global Git facts, per-candidate-set evidence, project input digest, and terminal-evidence validity are computed once per command. Mutating commands never install the scope; the Git index race guard still re-reads index contents every collection.
  • correct-owner validates pre-existing corrections once up front and resolves canonical module ownership at most once per module (fail-fast entry naming and error messages unchanged).
  • The bounded Git runner polls on a 200µs quantum instead of 2ms.

Measured (debug builds, 20/50 chained changes, half accepted)

Command Before After
change check @20 11.2s (3621 git spawns) 1.4s (599 spawns)
change list @20 13.0s 1.9s
change list @50 30.6s 3.8s
change check @50 16.0s 4.1s
correct-owner 20-entry batch 19.9s 0.25s

Scaling is now near-linear. Regression tests (read_scope_memoizes_repeated_summary_git_lookups, read_scope_reuses_git_evidence_for_repeated_candidates) assert identical summaries with strictly fewer git subprocess spawns (spawn-count hooks, no wall-clock timing). Full cargo test green (except one pre-existing root-only failure) and cargo clippy -- -D warnings green.

Closes #439

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ Corvin says...

      _
    <(;\  .oO(oh no...)
     |/(\
      \(\\
      " "\\

"Caw... your imports are all over the place."

CI Summary

Check Status
Validate action.yml ✅ Passed
Packaged Action Consumer ❌ failure
Dependency Audit ✅ Passed
Code Coverage ❌ failure
Format Check ✅ Passed
Docs Site ✅ Passed
Spec Validation ❌ failure
Tests (build, test, clippy) ❌ failure
VS Code Extension ✅ Passed

Powered by corvid-pet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lifecycle performance cliffs — change check superlinear at 20 changes; change list ~190ms/change; correct-owner batch ~4-8s/entry

1 participant