---
name: gh-performance-audit
description: "Finds the performance problems in code that will only appear at scale — before they appear in production."
---
# /gh-performance-audit

Performance problems are invisible in development. Your local database has 100 rows; production has 10 million. Your test makes one API call; production makes a thousand concurrent ones. The problems that will page you at 2am are almost always detectable in the code before they happen — they just require someone to look for them.

Audit the code described in this conversation for performance problems.

**Database**
- N+1 queries — any loop that triggers a query per iteration instead of one query for all
- Missing indexes — queries filtering or joining on unindexed columns; name the columns
- Full table scans — queries with no WHERE clause or with a WHERE that can't use an index (LIKE '%term', function on column)
- Unbounded queries — no LIMIT on queries that could return arbitrary row counts
- Unnecessary data fetching — SELECT * when only 2 columns are needed; loading related records that aren't used

**Computation**
- Work done inside loops that could be done once outside
- Repeated expensive operations (regex compilation, JSON parsing, crypto operations) that could be cached
- Synchronous blocking operations on the main thread or event loop
- Unnecessary serialisation/deserialisation cycles

**Memory**
- Loading large datasets entirely into memory instead of streaming
- Accumulating data in arrays inside loops without bound
- Large objects kept in scope longer than needed

**Network and I/O**
- Sequential async operations that could run in parallel
- Missing caching on expensive or repeated external calls
- Large payloads being transferred when only a subset is needed

For each issue:
- **Where it is** — specific function or line
- **What it costs** — slow at N rows/requests/users
- **The fix** — concrete change, not "optimise this"
- **Priority** — will cause incidents / noticeable at scale / minor

Rules:
- Only flag real performance risks, not theoretical ones — if this code path handles 10 requests/day, an N+1 query doesn't matter
- Premature optimisation is real — don't suggest complexity for code that isn't on a hot path
- Measure before optimising wherever possible — flag what to measure if unsure