pprof Bottleneck Hunt
Source: Custom
Topics: go tool pprof, CPU profiling, memory profiling, Go runtime/GC
Problem
This package is not a stub — pprof_bottleneck.go already passes its tests. Your job is to
profile it, find the bottlenecks, and optimize without changing behavior.
Two functions, two different problems:
CountLevels(lines []string) map[string]int — counts log levels ("[INFO] ..." → INFO).
Has a CPU bottleneck.
BuildCSV(rows [][]string) string — joins rows into CSV text.
Has a memory/allocation bottleneck.
Task:
- Run the benchmarks with profiling enabled (see below).
- Use
go tool pprof to find the hot spots — look for a function that shouldn't be appearing
so often, or an allocation source that should be a single allocation.
- Fix both functions. Tests in
pprof_bottleneck_test.go must still pass.
- Compare benchmark numbers before and after.
Don't peek at solution/ until you've found both issues yourself.
Profiling workflow
# Run benchmarks and write profiles
go test -bench=. -benchmem -cpuprofile=cpu.out -memprofile=mem.out \
./challenges/profiling/pprof-bottleneck/
# Top CPU consumers
go tool pprof -top cpu.out
# Top allocation sources (by space)
go tool pprof -top -alloc_space mem.out
# Interactive — type "top", "list <funcname>", "web" (needs graphviz)
go tool pprof cpu.out
Key concepts
regexp.MustCompile in a hot loop: compiling a regex is expensive (parsing + building an
NFA) — doing it once per call instead of once per program is a classic CPU bottleneck.
- String concatenation with
+=: each += allocates a brand-new string and copies
everything so far — O(n²) total work and allocations for n appends. strings.Builder grows
a buffer geometrically, like append on a slice.
-alloc_space vs -alloc_objects: -alloc_space shows total bytes ever allocated
(great for finding O(n²) copying); -alloc_objects shows allocation count (great for
finding per-iteration allocations that GC has to collect).
Run
go test -v -bench=. -benchmem ./challenges/profiling/pprof-bottleneck/
Sign in to submit your solution.