Profiling

Profiling exists because human intuition about where a program spends its time is unreliable. The 90/10 rule (roughly 90% of runtime lives in 10% of the code) means that optimizing the wrong function costs real time for zero benefit. Always profile before optimizing, and re-profile after — the hot path often moves once the biggest bottleneck is fixed.

perf is the standard Linux profiler — it samples the program's call stack at a fixed frequency using hardware performance counters, with very low overhead.

cProfile instruments every function call, which is precise but adds real overhead and can distort timing. py-spy instead samples a running process from the outside — no code changes, works on processes you didn't even start with profiling in mind, and safe to attach to production.

A flame graph turns thousands of stack samples into one picture. Each box is a function; the box's width is proportional to how often it appeared in a sample (i.e. how much total time it or its children consumed) — width is what to look at, not the x-position (which usually has no chronological meaning). Stacking (a box sitting on top of another) shows the call relationship: the box on top was called by the box below it. Wide, flat plateaus near the top of the stack are exactly the "10% of code, 90% of time" functions worth optimizing first.