pprof CPU Profiling, Memory Allocation Profiling, Execution Tracer
- Last updated
- Prerequisites:
- Go programs and HTTP servers
- Understanding of performance analysis concepts
- go
- pprof
- profiling
- execution-trace
- cpu
- memory
Read at your depth
The practical view
Go profiling: import _ "net/http/pprof" and hit /debug/pprof/ endpoints. CPU profile: go tool pprof http://localhost:6060/debug/pprof/profile (samples for 30s). Heap profile: .../debug/pprof/heap. Then analyze with go tool pprof: top, list, web. The execution tracer: go run -trace trace.out and analyze with go tool trace — shows goroutine scheduling, GC, and system events over time. CPU profiling answers 'where is CPU time spent'; heap profiling answers 'where are allocations coming from'; the tracer answers 'why is my program waiting/slow in time'. Use pprof for CPU/memory hot spots, trace for concurrency/scheduling problems.
The same idea in other frameworks
N/A — Go tooling concern.N/A — Go tooling concern.N/A — Go tooling concern.N/A — Go tooling concern.Legacy vs modern
Guessing performance vs profiling
Optimizing by intuition targets the wrong code; pprof shows where CPU and allocations actually go, and the tracer shows scheduling waits.
// ❌ OLD: optimizing what 'feels slow' without measuring// ✅ NEW: capture a CPU profile, find hot spots, optimize, re-profile
// go tool pprof -top http://localhost:6060/debug/pprof/profileInterview gotchas
Context
This tests the profiling methodology — interviewers want the SIGPROF sampling mechanism, the statistical nature, and the blind spots (short-lived functions, I/O waits).
The mechanical answer
The CPU profiler interrupts each thread with SIGPROF at a fixed rate (default 100 Hz) and records the current stack. It's SAMPLING, not instrumenting every call: hot functions accumulate proportionally more samples, so after enough samples the distribution approximates where CPU time is spent. Limitations: very short-lived functions that complete between samples can be missed; functions called rarely but each expensive may be under-sampled; the profile reflects CPU time ON the thread, not wall-clock waits — a goroutine blocked on I/O or a channel produces no CPU samples, so a CPU profile will NOT show 'waiting' problems. For waits, use the execution tracer or block profiles. Also, sampling rate and duration matter: short profiles may not represent steady state.
Trap
The naive answer is 'the profile shows everything the program did'. It samples CPU on-thread stacks; I/O waits and lock blocks are invisible in the CPU profile. Another trap: profiling for 1 second and trusting the distribution — run long enough (30s+) for statistical significance, and under realistic load. Candidates who describe the sampling mechanism and the CPU-vs-wait distinction show real understanding.
Context
This tests tool selection — interviewers want the question each tool answers and the overhead trade-off, which determines the right diagnostic for a symptom.
The mechanical answer
A CPU profile answers 'where is CPU time spent?' — sampled stacks of on-thread execution; use it for CPU-bound hot spots (a function eating 80% of samples). A heap profile answers 'where do allocations come from?' — sampled allocation stacks, reported as live (inuse) or cumulative (alloc), by space or objects; use it for GC pressure, high allocation rates, or memory growth. The execution tracer answers 'why is the program slow in TIME?' — it records every scheduling event (goroutine lifecycle, syscalls, GC, timers) with timestamps, so you can see a goroutine blocked on a channel, a mutex convoy, GC spikes, or network waits that no CPU profile shows. Overhead: CPU/heap sampling is cheap; the tracer is heavier (records every event) and is meant for targeted analysis, not always-on production.
Trap
The naive answer is 'the tracer replaces profiling'. They answer different questions — the tracer shows waits/scheduling, not CPU hot spots. Another trap: using the heap profile's default (inuse_space) when you need cumulative allocations to find allocation-rate problems — use -alloc_space. Candidates who map symptoms to tools show real diagnostic skill.