A profiler answers the question “where does my program actually spend its resources?” with measurement rather than guesswork. The two quantities most often profiled are time (which functions, lines, or instructions consume the most CPU) and memory (which allocation sites hold or churn the most bytes). Because asymptotic analysis tells you how a program scales but not which constant-factor hotspots dominate a real workload, profiling is the empirical complement to the kind of reasoning captured in big-O notation: it tells you where to spend optimization effort on the input you actually run.
There are two fundamental collection methods. Statistical sampling interrupts the program at a fixed rate, recording the program counter (and often the call stack) at each interrupt; the fraction of samples landing in a given function approximates the fraction of time spent there. The GNU gprof manual describes exactly this mechanism and devotes a section to the resulting “Statistical Sampling Error,” since sampling estimates carry sampling noise that shrinks as the run gets longer. The alternative is instrumentation, in which the compiler or tool inserts counting and timing code at function entry and exit (or around basic blocks). Instrumentation gives exact call counts and precise attribution but perturbs the program it measures, so heavily instrumented code runs slower and can distort the very timings it reports.
Profiler output also comes in two shapes. A flat profile lists each function with its own self time and call count, ranked so the biggest consumers float to the top. A call-graph profile goes further: it attributes the time spent inside a function back to the callers that invoked it, so a cheap-looking utility routine called from many places shows its true aggregate cost and its distribution across callers. The gprof paper, “gprof: a Call Graph Execution Profiler” (Graham, Kessler, and McKusick, SIGPLAN 1982), introduced exactly this idea: accounting for the running time of called routines within the running time of the routines that call them, which is what makes a call graph more actionable than a flat list.
Modern practice layers these ideas. Sampling profilers that capture full stacks (such as the Linux perf tool) produce huge volumes of stack traces, which visualizations like the flame graph then collapse into a readable picture of where time goes. The conceptual division established in the early 1980s, sampling versus instrumentation and flat versus call-graph, still organizes how performance engineers think about and read a profile today.