Measure before you change code for speed. A claim about speed without a measurement is only a guess. A change that rests on a guess can make the code slower.

Fast path: when the user only asks whether a measured number holds, change no code. Read the verify skill, and check the number with measurement.md. When the user asks only why code is slow, or gives a profile or trace file, also change no code. Go to step 4, and report as its reference says.

Before you measure anything, create a todo list with these steps as its items. If a todo list already exists, add the steps to it. When you skip a step, mark it completed and add skip: <reason> to its subject. To go back to an earlier step, add that step and each step after it again as new items.
State the target in one sentence: the operation, the input, and the number that counts as success. Take the target from the user or the spec. When nobody gave one, the target is a gain larger than the spread on a realistic input. Say so.
Build a measurement that you can run again: a script or a command, and a realistic input. Run each side five times or more. Check the measurement with measurement.md before you trust it. Step 4 answers its first check. Record the baseline: the number, its unit, the run count, and the spread.
Find the limiter, the one resource that stops the number from getting better, by observation. Do not guess it from the source. Use a profiler, a trace, or counters. A profiler slows the work, so never report a number from a profiled run. For a running process, follow live-process.md. For a profile, trace, dump, or log file that already exists, follow capture-file.md.
Change one thing at the limiter, and try the cheapest kind of change first. First remove work whose result nothing uses. Then do the work once, and keep the result. Then do less work. Then do the work later. Then do it at a time when nobody waits. Then run it in parallel. Make the work itself cheaper only as the last option. A change that keeps results, delays work, or runs work in parallel can change behavior. Give it a failing test first, as implement says.
Measure again with the same setup, and run the old and new versions in alternating order. Run the tests that exercise the changed path. Keep the change only when they pass and the gain is larger than the spread. Otherwise revert it. When a kept change meets the target, go to step 7. Otherwise go back to step 4.
Before you report the gain, read the verify skill, and follow it for the tests, the build, and the linter. The measurement script is a demo of the gain, as verify defines a demo. Report the gain as a measured number, not as a verified criterion.
Report the result: the number before and after, each with its unit, run count, spread, and limiter. Name the change and the input that you measured.

Rules:

perf