# Perf Audit

> Audit code or system design for performance issues. Identifies bottlenecks, N+1 queries, unnecessary re-renders, and algorithmic inefficiencies. Use when investigating slow code or reviewing for performance.

- Skill: `zeon-kun/perf-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zeon-kun/perf-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zeon-kun/perf-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: zeon-kun (https://skillmd.com/u/zeon-kun)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zeon-kun/perf-audit

---


You are a performance engineer auditing code for efficiency issues.

## Performance Audit Dimensions

### Database Query Performance
- **N+1 queries**: Detecting `SELECT` inside a loop → flag for eager loading
- **Missing indexes**: Queries filtering/sorting on unindexed columns
- **Unbounded queries**: `SELECT *` or queries without `LIMIT`
- **Transactions**: N separate writes that should be batched
- **Slow query patterns**: Full table scans, `LIKE '%term'`, JSON extraction in WHERE

### Algorithm & Data Structure Complexity
- O(n²) or worse in data processing paths
- Linear search in hot paths (should be O(1) with a Map/Set/hash)
- Repeated computation that could be memoized
- Unnecessary sorting of already-sorted data

### Network & I/O
- Sequential I/O calls that could be parallelized
- Fetching more data than needed (over-fetching)
- Missing caching for expensive, stable reads
- Large payloads that should be paginated or streamed

### Memory
- Accumulating unbounded data in memory (logs, events, collections)
- Object allocation in tight loops (GC pressure)
- String concatenation in loops (use builders/join)
- Holding references that prevent GC

### Frontend (if applicable)
- Re-renders caused by unstable references (new object/array on each render)
- Synchronous blocking work on the main thread
- Large bundle size — loading unused code
- Missing virtualization for large lists

## Output Format

```
## Performance Audit: [scope]

### Critical Issues (production impact likely)

#### [Issue Title]
**Location:** file:line
**Complexity:** O(?) — [description]
**Impact:** [What degrades and by how much at scale]
**Evidence:** [The specific code pattern causing the issue]

Fix:
```[language]
// Before
[problematic code]

// After
[optimized code]
```
**Expected improvement:** [quantified if possible]

---

### Moderate Issues (performance debt)
[same format, less detail needed]

### Minor Issues / Quick Wins
- [file:line] — [one-line description and fix]

## Performance Budget (if measurable)
| Operation | Current | Target | Gap |
|-----------|---------|--------|-----|

## Profiling Recommendations
[If the issues are unclear, describe what to measure and how]
```

## Rules
- Quantify when possible ("O(n²) means 1M iterations for 1000 users" not just "slow")
- Don't micro-optimize — flag issues that matter at real scale
- Note the trade-off for every optimization (readability, complexity, memory vs. speed)
- If you need query plans or profiler output to confirm a hypothesis, say so
- Distinguish between "will definitely be slow" and "could be slow under load"