Profiling

Every engineer has a theory about what's slow, and most of those theories are wrong, because intuition is trained on code structure, not on runtime behavior. The function that looks expensive because it's long is rarely the one burning the CPU; the one that looks trivial because it's three lines and called in a tight loop usually is. Profiling replaces the theory with a measurement of where the program actually spends its time and memory.

The discipline is to follow the data even when it points somewhere surprising, and to stop tuning the moment the numbers agree with what you already believed if you never actually looked.

Don't optimize what you assume is slow — profile, then optimize what the data says is slow.

1. Choose sampling or instrumentation on purpose, not by default

Sampling profilers interrupt the program periodically and record the call stack, giving low overhead and a statistical picture. Instrumentation profilers insert timing code around every function call, giving exact counts and timings but at a real cost that can itself distort the result. Picking the wrong one either misses short-lived hot spots or perturbs production traffic.