Course Preview

Software Profiling

Profiling measures where a running program spends its time and memory, attributing that cost to the specific functions and call paths responsible. It answers the question a log line or a request timing cannot: not that an operation was slow, but which code inside it was slow, and how much of the total that code accounts for.

itObservability and performance | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic — Software Profiling

Software profiling is the practice of measuring where a running program spends a resource and attaching that cost to the call stacks responsible. It exists because “the service is slow” is a perfectly accurate statement with almost no useful steering information. A request timer can report eight hundred milliseconds. A profile can show that a particular path consumed a large share of the CPU beneath it. That is the difference between a weather report and a map.

The machinery is less mystical than its graphs suggest. A profiler notices an event, captures the stack, turns addresses into names through symbolization, and merges matching stacks into weighted totals. The merge is the useful bit and the annoying bit. It reduces millions of observations into something a human can read, but it also discards their order. A flame graph is not a tiny cinema of the program's day. Its width shows how often a frame appeared; its horizontal position is not time, despite looking extremely time-shaped.

The first fork in the road is sampling versus instrumentation. Sampling takes periodic observations, so its overhead follows the sample rate rather than the number of calls. That makes it the normal production choice. Instrumentation observes every call and can give exact counts, but its cost follows the work being measured and can alter the ratios under inspection. Exactness has a bill, as these things tend to do. Use it on a development machine when call counts matter.

Then choose the resource before admiring any output. A CPU profile sees threads that are running. A slow request waiting on a lock, disk, or database can leave that profile nearly empty, which is not a profiler sulking. It is evidence that the time is off-CPU and needs a wall-clock, block, mutex, or off-CPU profile. Likewise, allocation rate identifies garbage-collection pressure, while an in-use heap profile identifies memory still retained. Similar nouns have caused more than one long afternoon.

Read the Course tab for the collection path, the trade-offs in stack unwinding, and the limits of each profile type. The Cheatsheet is the compact reference when a graph contains mysterious main children or unknown addresses. The Practice tab supplies commands for perf, Go, Python, JVM, and .NET. Field Notes carries the operational traps that profiles politely decline to put in the title. The Quiz checks whether the vocabulary has become a working map rather than an attractive pile of rectangles.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources