# Measure Before Optimizing

> Use when asked to improve performance, or when about to optimize code believed to be slow

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

---


# Measure Before Optimizing

No optimization without a measurement. Intuition about where time goes is wrong often enough that acting on it produces complexity without speed.

## The cycle

1. **Measure first.** Profile, time, or count queries on a realistic workload. Find the actual hotspot — not the code that "looks slow".
2. **State the baseline.** "X takes 2.3s, target is under 500ms." Without a number, nothing can be proven later.
3. **Fix the biggest cost first.** It is usually structural — N+1 queries, O(n²) loops, missing index, repeated work inside a loop, chatty I/O — not micro-level (string concatenation, function call overhead).
4. **Re-measure the same workload.** Report before/after numbers. Without them, the claim is just "I changed something".

## Heuristics

- Batching and killing N+1 patterns beat any micro-optimization by orders of magnitude.
- Cache only with an invalidation story — a stale cache trades a speed problem for a correctness bug.
- Don't trade readability for unmeasured gains; do trade it for a measured 10x.
- Parallelism added "for speed" without measurement usually adds race conditions, not speed.

## Red flags

"This should be faster", optimizing in the middle of an unrelated task, preemptive caching or parallelization. All of these mean: measure first, or leave it alone.