Performance Skill

Overview

Premature optimization is the root of all evil. This skill guides systematic performance analysis—measure first, then optimize.

Core principle: Never optimize without profiling. Guessing at bottlenecks wastes time and often makes things worse.

The Performance Process

Phase 1: Measure First

Before changing ANY code:

1. Define the Problem

   • What specifically is slow?
   • How slow is it? (numbers, not feelings)
   • What is acceptable performance?

2. Establish Baseline

   • Measure current performance
   • Use realistic data sizes
   • Record the numbers

3. Profile, Don't Guess

   • Use profiling tools (not intuition)
   • Identify actual bottleneck
   • See references/algorithm-complexity.md for patterns

Phase 2: Analyze

Find the real bottleneck:

1. Check Complexity

   • What's the Big O of this code?
   • Is there a nested loop making it O(n²)?
   • Is there repeated work that could be cached?

2. Check I/O

   • Database queries in loops (N+1)?
   • Network calls that could be batched?
   • File operations that could be buffered?

3. Check Memory

   • Loading more data than needed?
   • Creating unnecessary copies?
   • Memory leaks?

Phase 3: Optimize

Fix the bottleneck, measure again:

1. Target the Bottleneck

   • Only optimize what profiler identified
   • Don't optimize "while you're in there"

2. Measure Improvement

   • Did it actually get faster?
   • By how much?
   • Any regressions elsewhere?

3. Document the Change

   • What was the bottleneck?
   • What was the fix?
   • What was the improvement?

Red Flags - STOP and Profile

Complexity Red Flags

- Nested loops over collections
- .includes() or .indexOf() inside loops
- String concatenation in loops
- Recursive functions without memoization
- Sorting inside loops

Database Red Flags

- Query in a loop (N+1 problem)
- SELECT * when only need few columns
- Missing indexes on filtered/sorted columns
- LIKE '%value%' (can't use index)
- Large IN clauses

Memory Red Flags

- Loading entire dataset into memory
- Storing derived data that could be computed
- Not using pagination for large results
- Unbounded caches
- Retaining references to unused objects

Common Rationalizations - Don't Accept These

Performance Checklist

Before approving performance-sensitive code:

• Measured: Do we have baseline numbers?
• Profiled: Did we use tools to find bottleneck?
• Complexity: Is algorithmic complexity appropriate?
• N+1: No database queries in loops?
• Indexes: Queries use appropriate indexes?
• Pagination: Large results are paginated?
• Verified: Did we measure improvement?

Quick Complexity Reference

Quick Profiling Commands

# Node.js
node --prof app.js
node --prof-process isolate-*.log > profile.txt

# Python
python -m cProfile -s cumtime script.py
py-spy record -o profile.svg -- python script.py

# Go
go test -bench=. -cpuprofile=cpu.prof
go tool pprof cpu.prof

# Browser
# DevTools → Performance tab → Record

Performance Hierarchy

Focus optimization efforts in this order (highest impact first):

1. Architecture    - Wrong design = can't optimize later
2. Algorithms      - O(n²) to O(n) = 1000x improvement
3. Database        - Missing index = table scans
4. I/O             - Network, disk, blocking calls
5. Memory          - Leaks, excessive allocation
6. Micro           - Loop unrolling, etc. (rarely needed)

References

Detailed patterns and examples in references/:

• algorithm-complexity.md - Big O reference and optimization patterns
• database-performance.md - Query optimization and indexing
• caching-strategies.md - When and how to cache
• frontend-performance.md - Bundle size, Core Web Vitals
• profiling-tools.md - Language-specific profiling guides