Performance Profiling

WHY IT EXISTS Developers routinely guess wrong about what makes code slow. Optimizing the wrong function wastes effort and can add complexity for no gain. Profiling exists to give empirical evidence of where time and memory actually go, so optimization is targeted and measurable.

THE MENTAL MODEL A profiler is a stopwatch and accountant attached to your program. It answers two questions: where does the resource go, and how is that cost reached through the call graph. You read it top-down to find expensive subtrees and bottom-up to find expensive leaf functions called from everywhere.

HOW IT WORKS Sampling profilers interrupt the program many times per second and record the current stack; over many samples the statistics approximate time distribution with low overhead. Instrumenting profilers wrap function entry and exit to count exact invocations and durations, accurate but heavier and capable of distorting timings. Allocation profilers track heap growth by call site. Results aggregate into flame graphs where frame width equals cost.

WHEN IT MATTERS Profile when latency or cost regresses, before a major optimization effort, or when capacity planning needs to know which paths dominate. It matters especially under realistic load, since hotspots under production traffic differ from those in a microbenchmark.

ONE CONCRETE EXAMPLE An API endpoint shows p99 latency of two seconds. The team assumes the database is slow and considers adding caches. A CPU profile under load instead shows sixty percent of time in JSON serialization, repeatedly re-encoding an unchanged config object per request. Caching the serialized config once cuts p99 to four hundred milliseconds, a fix the team would never have found by guessing at the database.