Execution tracing

Canonical guidance

• use traces for interaction-heavy latency problems
• capture focused traces around the suspect window
• combine trace evidence with profiles and benchmarks

Use when

• scheduler delays
• lock contention or blocking
• GC pauses affecting latency
• bursty request-path investigations

Avoid

• capturing giant traces first and hoping the answer appears
• using tracing when a simple CPU or heap profile would suffice
• interpreting a trace without a concrete question

Preferred pattern

go test -trace trace.out ./...
go tool trace trace.out

Anti-pattern

• treating execution tracing as the default first step for every performance question

Explanation: This anti-pattern is tempting because traces are rich, but they are heavier and harder to read than simpler tools.

Why

• tracing shines when the bug is about interactions over time, not just aggregate resource cost