Performance Audit

Find where a path plausibly hot carries a performance hazard — work that scales badly with input or load — and surface each as a finding. Run the shared audit method in ../AUDIT-METHOD.md with the lens, sub-dimensions, and dimension below.

The aim is risk-weighted hazards on hot paths, not micro-optimisations on cold code. A redundant allocation in a once-at-startup path is noise; the same allocation per request, per row, or per event is the concern. Findings name the hazard and the hot-path evidence — why this path matters — never a style preference.

Risk lens (step 1)

Map the codebase's hot paths from its entry points and loop structure, then rank by how often the work runs and how it scales:

• Per-request / per-event — request handlers, message consumers, render loops, anything that runs once per unit of incoming work and multiplies a single hazard across traffic.
• Loops and recursion — per-iteration work inside a loop, especially one whose bound grows with input or a collection size.
• Data-volume paths — code that fetches, scans, or transforms collections whose size is caller- or data-driven, where cost grows with the row count.

Rank by exposure — a hazard on a per-request path scaling with input outranks one on a cold or fixed-size path.

Current state: confirm the path is hot and unmitigated (step 2)

For each candidate, confirm two things before it counts: the path is genuinely hot, and nothing already absorbs the cost. A mitigation existing somewhere is not the same as guarding this path — trace whether it applies:

• A cache, memoisation, or batch/eager-load that already collapses the repeated work.
• An index or query plan that already makes the access cheap.
• A bound, limit, or pagination that already caps the result set.
• A path that runs once or over a fixed small size — cost that never scales is not a hazard.

Sub-dimensions to sweep (step 3)

• N+1 data access — a query, fetch, or remote call issued per row of a prior result instead of once in a batch.
• Per-iteration allocation or IO — allocation, IO, or expensive computation inside a loop that could be hoisted, batched, or amortised.
• Unbounded reads — collection fetches with no pagination or limit, loading data whose size grows with the dataset.
• Missing caching or indexing — repeated identical computation or a lookup whose access pattern demands an index but has none.
• Blocking in async contexts — a synchronous or blocking call inside an async path, stalling the event loop or starving the pool.

Drop low-confidence noise — a hazard on cold code, or one a mitigation already covers, is not a finding.

Dimension (step 4)

• Dimension — performance (the sub-dimension goes in the title/evidence, e.g. "N+1 query loading order line items per order in …", "unbounded fetch of all users in …" — never as a new top-level dimension)
• Suggested category — enhancement (hardening a hot path against a hazard); a hazard already degrading production latency or exhausting a resource is a bug
• Where — the hot path's module / type / function
• Evidence — the hazard, why the path is hot (the hotness justification, not a style claim), that no mitigation covers it, and how the cost scales

Handover

Per ../AUDIT-METHOD.md → Handover.

• artifact: findings (in ../contracts/finding.md shape)
• default: capture — dedups against open issues, culls, files survivors as needs-triage
• alternatives: stop (review the findings yourself first)