Performance Profiling
Profiling measures where a program actually spends its time and resources, attributing CPU cycles, memory, or wall-clock latency to specific functions or call paths. It replaces guesswork with data so optimization effort targets the real bottleneck.
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.
Interview question
Why might a team prefer a sampling profiler over an instrumenting profiler when diagnosing a production latency issue?
- a.Sampling profilers measure only memory, never CPU time
- b.Sampling profilers add low overhead, so they distort timings less under loadCorrect
- c.Sampling profilers record every function call for perfect accuracy
- d.Instrumenting profilers cannot produce flame graphs at all
Why? this is the answer
Sampling has low, predictable overhead, making it safer under production load. Instrumenting profilers capture exact counts but their per-call overhead can distort the very timings you are measuring.
Just read this? Test yourself on what you have been reading.
- #profiling
- #performance
- #optimization
- #flame-graph
- #cpu
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on profiling — each one lists the topics its interview covers.
See open roles