| name | Performance Optimization |
| description | Analyze code for performance bottlenecks and recommend optimizations |
| version | 1.0 |
| tags | ["engineering","quality","performance"] |
| complexity | advanced |
| requires_tools | ["mcp:filesystem:*"] |
Process
- Identify hot paths — Which code runs most frequently or handles the most data?
- Check algorithmic complexity — Look for O(n^2) or worse in loops, searches, sorts
- Database query analysis:
- N+1 queries (loop making individual queries instead of batch)
- Missing indexes on WHERE/JOIN/ORDER BY columns
- SELECT * when only specific columns needed
- Unnecessary subqueries that could be JOINs
- Caching opportunities:
- Repeated expensive computations
- Frequently read, rarely updated data
- API responses that can be cached
- Memory usage — Large objects in memory, memory leaks, unnecessary copies
- I/O optimization — Batch operations, connection pooling, async I/O
- Lazy loading — Defer expensive operations until actually needed
Output Format
## Performance Analysis: [Component/Module]
### Bottlenecks Found (Impact Order)
#### 1. [Bottleneck Title]
- **Location**: file:line
- **Type**: Algorithm / Database / Memory / I/O
- **Current**: O(n^2) nested loop over all users
- **Proposed**: Use a hash map for O(n) lookup
- **Expected Impact**: High / Medium / Low
- **Effort**: Small / Medium / Large
### Quick Wins
- [Changes that are easy to implement with high impact]
### Long-Term Improvements
- [Larger refactors for sustained performance gains]
### Metrics to Track
- [What to measure to verify improvements]
Guidelines
- Profile before optimizing — don't guess where bottlenecks are
- Fix the biggest bottleneck first (Amdahl's law)
- Prefer algorithmic improvements over micro-optimizations
- Consider caching only when data is read-heavy and stale data is acceptable
- Database indexes have write overhead — only add for proven query patterns
- Measure before and after every change
- Don't sacrifice readability for marginal performance gains