Week 15: Performance & Profiling with pprof

1. CPU & Memory Profiling with net/http/pprof

Importing net/http/pprof for its side effects registers a set of profiling endpoints on the default mux — genuinely one import line to add real-time profiling to a running service.

import (
    "net/http"
    _ "net/http/pprof" // registers /debug/pprof/* on the default mux
)

func main() {
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil)) // separate port, not exposed publicly
    }()
    // ... the real application server, as before
}

# a 30-second CPU profile, while generating real load against the app
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# a snapshot of current heap allocations
go tool pprof http://localhost:6060/debug/pprof/heap

pprof's debug endpoints should never be exposed on the same port as public traffic in production — running them on a separate, internal-only port (as above) is standard practice.

2. Reading a Flame Graph

go tool pprof -http=:8081 http://localhost:6060/debug/pprof/profile?seconds=30

This opens an interactive web UI. A flame graph stacks function calls vertically — each frame's width represents how much total time was spent in that function (including everything it called), not how long any single call took. A wide frame near the top of the stack is exactly where to look first: it means real time is genuinely being spent there, not just passed through to something below it.

A narrow frame, even one that looks alarming by name, isn't worth chasing — the graph's width is the actual signal; everything else (color, position) is incidental. This is the direct, visual answer to what Week 9's ns/op and allocs/op numbers could only hint at in aggregate.

3. Reducing Allocations

A heap profile commonly surfaces the same handful of causes, each traceable back to Week 5's escape analysis.

// before — allocates a new slice on every call
func FormatTasks(tasks []Task) []string {
    var result []string // nil slice, grows via repeated reallocation
    for _, t := range tasks {
        result = append(result, t.Title)
    }
    return result
}

// after — one allocation, sized up front
func FormatTasks(tasks []Task) []string {
    result := make([]string, 0, len(tasks)) // capacity known in advance
    for _, t := range tasks {
        result = append(result, t.Title)
    }
    return result
}

Pre-sizing with make([]T, 0, n) when the final length is known (or closely estimable) avoids the repeated reallocate-and-copy cycle from Week 4's append behavior — a small, mechanical change, but one that shows up directly and measurably in a benchmark's allocs/op.

4. Avoiding Premature Optimization

Every technique above is only worth applying to a bottleneck a profile actually identified — optimizing code the profile shows spending 0.1% of total time is wasted effort that also makes the code harder to read, for no measurable benefit.

• Profile first, always — intuition about where time goes is wrong more often than not, even for experienced engineers.
• Optimize the widest frame in the flame graph, not the function that merely looks inefficient by inspection.
• Re-profile after each change — confirm the fix actually moved the bottleneck rather than assuming it did.
• Stop once the bottleneck that actually mattered for real usage is gone — chasing diminishing returns past that point is its own form of waste.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.