Reading parent and child chains: where to apply the fix

A senior engineer opens pprof and looks at json.Marshal at 28% CPU. They do not reach for a faster JSON library. They check the parent chain. One wide parent: a request logger. The fix is not the library — it is the logger calling Marshal on every request regardless of log level.

Reading the parent chain

The parent chain answers: “where does this wide leaf get called from?”

Concentrated fan-in (one wide parent path): the leaf is called repeatedly from a single location. Fix the caller — call less often, cache results, batch, or eliminate the call.

Distributed fan-in (many narrow parents): the leaf is shared infrastructure used by many callers. Fix the leaf itself, because optimising any one caller leaves the other nineteen unchanged.

The classic example: json.Marshal wide with one wide path from a logger means the logger is the bug — don’t switch JSON libraries, fix the logger. The same json.Marshal wide and called from twenty handlers means JSON is the bottleneck — switch libraries or pre-encode.

Production-grade pprof and Pyroscope let you switch between leaf-up and caller-down views with one click; using both is the senior reading habit.

Reading the child chain (self-time vs cum-time)

The child chain answers: “does this function do the work, or does it delegate to a callee?”

Self-time-heavy leaf with narrow children: the function is doing the work itself. Fix is inside the function.

Cum-time-heavy parent with thin self-time: this function is a dispatcher. The cost sits one level down in a callee. Fix the callee, not this layer.

The reading rule: walk from the leaf with high self-time down the parent chain. Find the level where cum-time drops sharply as you move up. That level is the “boundary of meaningful work” — above it is dispatch, below it is execution. Apply the fix inside that boundary.

Misreading this boundary is how teams end up rewriting middleware that wraps a slow database call, or optimising HTTP routers when the cost is in the handler body.

Fan-in amplification

When one function is called from many callers, optimising the leaf compounds across each caller. A 30% local improvement in a shared function used by twenty paths gives 30% on every one.

The inverse — fan-out: one caller hitting many callees — makes optimising each callee a single-path local saving.

Senior move: look at fan-in/fan-out shape before deciding leaf vs caller fix. High fan-in (shared infra) means leaf fix amplifies. High fan-out (one caller, many callees) means caller fix (batching, caching, eliminating the call) amplifies. This math often outweighs the fix-family choice: even a small fix on a high fan-in leaf can outscore a large fix on a single-caller path.

Bottom-up vs top-down views

pprof, Pyroscope, and Intel VTune all support two complementary views.

Bottom-up: rank functions by self-time, leaf-first. Best for finding which single function eats the most CPU.

Top-down: rank functions by cum-time from root, parent-first. Best for finding which subsystem is responsible for the most time.

Senior reading habit: open bottom-up first to name the hot leaf, then switch to top-down to see which entry-point owns it. A leaf that is hot under one entry-point is a localised fix; a leaf that is hot under many is shared infrastructure.