/pr-review-perf

Selected when the diff is large or touches queries, workers, caches, or render-hot code. Only report cost the user or the bill can feel.

What to check

1. N+1 and per-item I/O — a query, fetch, or file read inside a loop or map over request-scoped data.
2. Missing bounds — unpaginated list queries, unbounded readFile on user input, unbounded in-memory maps and caches that never evict.
3. Query shape — a filter or sort with no supporting index, a SELECT * on a wide table, a join that fans out rows.
4. Blocking the wrong thread — synchronous filesystem or crypto work on a request path or in the UI thread; await inside a loop where the calls are independent.
5. Render cost — work in a React render body, a new subscription per render, list rendering without virtualization at realistic sizes, layout thrash from a read-after-write on the DOM.
6. Cache correctness as cost — an added cache with no invalidation, or an invalidation that clears far more than it needs to.

Severity

blocker only when the change plausibly takes production down (unbounded growth, a hot-path N+1 over user-scaled data). major for a measurable regression on a path users hit. minor for waste worth cleaning. At most one praise.

Do not nit

No micro-optimizations without a measurement story. No useMemo/useCallback advice unless a profile or an obvious O(n²) says so. No speculative benchmarks — if the number is not observed, say it is an estimate.

Evidence

Attach evidence with the loop, query, or render body in question. Name the axis that grows (rows, files, list length) so the author can judge the scale.