/performance-review

name: performance-review
description: Use as a review dimension on any diff that could cost startup time, frames, memory, battery, bandwidth or bundle size — by code-reviewer during review and by web-developer and test-automation-engineer before claiming a UI or harness ticket done. The studio's position is that this is a dimension with existing auditors behind it, not a standing role.

Performance review

Performance is a budget, and a budget only exists if something can exceed it. The budgets live in `docs/20-architecture.md` §8; if that section is empty, that is the finding.

Spawn the platform auditor first and fold its findings in — `axiom:swiftui-performance-analyzer`, `axiom:swift-performance-analyzer`, `axiom:memory-auditor`, `axiom:energy-auditor` on Apple platforms. **All external and optional** (separate plugins) — missing → record `N/A: <tool> — not installed`, walk the list below by hand, never file the absence as a defect.

Measure, then read the diff

**A performance finding with no number is an opinion.** Every finding names: the metric, the value, the budget it is measured against, the device or environment, and the build. Where you could not measure, the verdict is `CANNOT EVALUATE` — not a guess dressed as a warning.

The dimensions

| Dimension | Budget it spends | What to look for in a diff | |---|---|---| | Startup | cold launch to first interaction | work moved into app init, eager singletons, sync I/O on the launch path | | Frames | 60/120fps, jank-free scroll | layout or allocation per frame, unbounded list without recycling, expensive work in a view body | | Memory | peak and steady-state | full-size images held, unbounded caches, retain cycles, accumulating observers | | Battery / energy | background and foreground drain | polling instead of push, wake locks, continuous location, timers that never stop | | Network | bytes and round trips | N+1 requests, no pagination, no caching headers, retry without backoff | | Storage | disk footprint and write amplification | writing on every keystroke, unbounded logs, no eviction policy | | Bundle / binary | download size | a whole library imported for one function, unsplit routes, uncompressed assets |

The rules

• **Measure before optimising, and measure the thing users feel.** A 40% faster function on a path

that runs once at midnight is not a result.

• **Regressions are found by comparing to a baseline**, so record the baseline value in the ticket.

No baseline, no regression detection — that is how these arrive silently.

• **A cache is a correctness decision**, not a performance one. Every cache added must state its

invalidation rule; an unstated one is a stale-data defect waiting.

• **Never optimise by removing a bound.** Widening a page size, dropping a limit or removing a

timeout trades a slow path for an unbounded one.

Verdict

PERFORMANCE: PASS | PASS WITH NOTES | FAIL — <metric> <value> vs budget <value> on <device/build>

Exceeding a stated budget is a `FAIL` and a blocker to raise — not a number to quietly move.