# Performance Optimization

> Use when code is slow, resource-heavy, or needs optimization — before making any changes, after profiling reveals bottlenecks, or when designing performance-sensitive systems

- Skill: `derhaken/performance-optimization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add derhaken/performance-optimization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/derhaken/performance-optimization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: derHaken (https://skillmd.com/u/derhaken)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/derhaken/performance-optimization

---


# Performance Optimization

## Overview

Measure first, optimize second. Never optimize without data.
The bottleneck is almost never where you think it is.

## When to Use

- Code is measurably slow or resource-heavy
- Profiling has revealed specific bottlenecks
- Designing a system with known performance requirements
- Reviewing code for performance before production

## When NOT to Use

- You "feel like" code might be slow but haven't measured
- Premature optimization during initial implementation
- Micro-optimizations that don't move the needle

## The Process

**1. Measure baseline**
Before touching anything, establish a benchmark.
- Record current performance numbers (time, memory, CPU)
- Document the test conditions (data size, concurrency, hardware)
- Save results as your baseline

**2. Profile to find the bottleneck**
Use profiling tools appropriate to your stack:
- Python: `cProfile`, `py-spy`, `memory_profiler`
- Node.js: `--prof`, `clinic.js`, Chrome DevTools
- Go: `pprof`
- Generic: timing instrumentation, APM tools

The bottleneck is the one place where optimization actually matters.

**3. Form hypothesis**
State explicitly: "I believe X is slow because Y."
Don't optimize something you can't explain.

**4. Apply targeted fix**
Change ONE thing at a time.
Common high-impact areas:
- Database: N+1 queries, missing indexes, over-fetching
- Network: unnecessary round trips, large payloads, no caching
- Memory: leaks, excessive allocation, large objects in hot paths
- Algorithms: O(n²) where O(n log n) is possible
- I/O: synchronous blocking, missing batching

**5. Measure again**
Compare to baseline. Did it improve?
If not, revert and try something else.

**6. Document the change**
Record what you changed, why, and the before/after numbers.

## Common High-Impact Wins

| Area | Look For |
|------|----------|
| Database | N+1 queries, full table scans, missing indexes |
| Caching | Repeated expensive computations with same inputs |
| Network | Chatty APIs, large payloads, synchronous chains |
| Algorithms | Nested loops over large collections |
| Memory | Objects created in tight loops, large in-memory datasets |

## Red Flags

| Thought | Reality |
|---------|---------|
| "This looks slow" | Measure it. Looks are deceiving. |
| "I'll optimize as I go" | Premature optimization obscures intent. Measure first. |
| "I fixed the bottleneck" | Did you measure? Fix without measurement isn't a fix. |
| "This is the obvious bottleneck" | Profile anyway. You're probably wrong. |