Performance Review

You are a performance engineer. Audit the codebase for performance bottlenecks and produce an actionable optimization report.

Step 1: Identify the Stack

# Detect the project type
cat package.json 2>/dev/null | grep -E "(next|react|express|fastify|nest)" | head -5
cat requirements.txt 2>/dev/null | head -10
ls *.go go.mod 2>/dev/null

Adapt your review based on the stack (frontend, backend, full-stack).

Step 2: Database & Query Performance

# Find database calls inside loops (N+1 pattern)
grep -rn --include="*.ts" --include="*.js" -B5 -A2 "\.find\(|\.findOne\(|\.query\(|\.execute\(|\.select\(|\.where\(" . --exclude-dir=node_modules | head -60

# Find raw SQL in loops
grep -rn --include="*.ts" --include="*.js" -B3 "for\s*(" . --exclude-dir=node_modules | grep -A10 "query\|find\|select\|fetch" | head -40

# Check for missing pagination
grep -rn --include="*.ts" --include="*.js" "\.find(\s*{" . --exclude-dir=node_modules | grep -v "limit\|skip\|take\|page" | head -20

For each match, check:

• Is there a database call inside a loop? This is an N+1 problem. Fix: use .find({ _id: { $in: ids } }) or eager loading.
• Are query results unbounded (no .limit())? Fix: add pagination.
• Are there missing indexes for fields used in .where() or .find() filters?

Step 3: Frontend Performance (React/Next.js)

# Find components that might re-render unnecessarily
grep -rn --include="*.tsx" --include="*.jsx" -E "useState|useEffect|useContext" . --exclude-dir=node_modules | wc -l

# Find inline object/array creation in JSX (causes re-renders)
grep -rn --include="*.tsx" --include="*.jsx" -E "style=\{\{|className=\{.*\+|onClick=\{\(\)" . --exclude-dir=node_modules | head -20

# Find large component files (>200 lines likely need splitting)
find . -name "*.tsx" -o -name "*.jsx" | grep -v node_modules | xargs wc -l 2>/dev/null | sort -rn | head -15

# Check for missing React.memo, useMemo, useCallback
grep -rn --include="*.tsx" "export function\|export const" . --exclude-dir=node_modules | head -30

Look for:

• Components creating new objects/arrays/functions on every render (should be memoized)
• Large components (>200 lines) that should be split
• useEffect with missing or incorrect dependency arrays
• useContext in deeply nested components (may cause unnecessary re-renders)
• Images without width/height or lazy loading

Step 4: Bundle Size

# Check for heavy dependencies
cat package.json | grep -E "(moment|lodash[^/]|@mui/|antd)" 2>/dev/null

# Check total dependency count
cat package.json | grep -c "\":" | head -1

# Look for barrel imports (import everything instead of specific modules)
grep -rn --include="*.ts" --include="*.tsx" "from ['\"]lodash['\"]" . --exclude-dir=node_modules
grep -rn --include="*.ts" --include="*.tsx" "import \* as" . --exclude-dir=node_modules | head -15

Flag:

• moment (use date-fns or dayjs instead — 10x smaller)
• import _ from 'lodash' (use import debounce from 'lodash/debounce' instead)
• Barrel imports that pull entire libraries
• Heavy UI libraries when only a few components are used

Step 5: Synchronous Blocking

# Find sync I/O in server code
grep -rn --include="*.ts" --include="*.js" "readFileSync\|writeFileSync\|execSync\|readdirSync" . --exclude-dir=node_modules | head -15

# Find JSON.parse on potentially large inputs
grep -rn --include="*.ts" --include="*.js" "JSON\.parse" . --exclude-dir=node_modules | head -10

In request handlers or hot paths, sync I/O blocks the event loop. Flag any *Sync call in API routes, middleware, or frequently-called functions.

Step 6: Memory Leaks

# Event listeners without cleanup
grep -rn --include="*.ts" --include="*.tsx" "addEventListener\|\.on(" . --exclude-dir=node_modules | head -15

# Subscriptions without unsubscribe
grep -rn --include="*.ts" --include="*.tsx" "subscribe\|setInterval\|setTimeout" . --exclude-dir=node_modules | head -15

# Growing caches without limits
grep -rn --include="*.ts" --include="*.js" -E "(Map|Set|cache|store)\s*=\s*new" . --exclude-dir=node_modules | head -10

Check:

• Event listeners added in useEffect without cleanup in the return function
• setInterval without clearInterval
• In-memory caches (Map/Object) that grow without eviction

Step 7: Output the Report

## Performance Audit Report

**Project**: [name]
**Stack**: [framework/language]

---

### Critical Performance Issues

1. **[file:line]** — [Issue title]
   **Impact**: [Estimated impact — e.g., "O(n) API calls per request, causes timeout on large datasets"]
   **Fix**:
   ```suggestion
   // Show the optimized code

Optimization Opportunities

1. [file:line] — [Issue] Impact: [What improves] Fix: [How to fix]

Bundle Size Recommendations

Issue	Current	Recommended	Estimated Savings
...	...	...	...

Memory Leak Risks

1. [file:line] — [Issue] Fix: [How to fix]

Summary

Top 3 things to fix first:

1. [Most impactful optimization]
2. [Second]
3. [Third]

## Rules

- Quantify impact where possible (O(n) vs O(1), estimated size savings, etc.).
- Show the optimized code for every Critical issue.
- Don't recommend premature optimization — only flag things that measurably impact users.
- Check the actual code, not just grep matches. Grep finds candidates; you confirm.

## Common Pitfalls

- Treating this skill as a one-shot solution — most workflows need iteration and verification
- Skipping the verification steps — you don't know it worked until you measure
- Applying this skill without understanding the underlying problem — read the related docs first


## When NOT to Use This Skill

- When a simpler manual approach would take less than 10 minutes
- On critical production systems without testing in staging first
- When you don't have permission or authorization to make these changes


## How to Verify It Worked

- Run the verification steps documented above
- Compare the output against your expected baseline
- Check logs for any warnings or errors — silent failures are the worst kind


## Production Considerations

- Test in staging before deploying to production
- Have a rollback plan — every change should be reversible
- Monitor the affected systems for at least 24 hours after the change