Profiling collects and analyzes measurements of a program’s execution: function activity, execution time, CPU use, memory use, goroutines, or other resource behavior. Unlike logs, profiles provide numerical evidence about what a service is doing. section 9.1.1 section 9.1
A profile can be gathered manually or automatically, locally or across longer periods as continuous profiling. Continuous profiling supports troubleshooting, performance optimization, and comparisons between service versions, while profiling remains focused on a service rather than a distributed request path. section 2.5 section 9.1
A practical profiling workflow can include:
- Expose profiles from an application or collector, commonly through a pprof-compatible HTTP endpoint. section 9.1.1
- Collect a time-bounded CPU profile, then inspect flat and cumulative function costs in an interactive query interface. section 9.1.1
- Store and query continuously collected profiles with a tool such as Parca, using visual flame-graph or icicle-graph views. section 9.1.5
Finding an expensive function
A Go service repeatedly runs quickTask() and slowTask() while exposing net/http/pprof. A 30-second CPU profile shows slowTask() accounting for about 49% cumulative runtime, compared with about 6% for quickTask(), turning an otherwise invisible performance difference into an actionable investigation. section 9.1.1
Profiling is useful in development and production, but interpretation and tool selection require care. Formats and tooling do not interoperate perfectly; open-source and commercial options differ, and collection mechanisms such as eBPF or language-specific instrumentation have operational implications. section 9.4 section 11.1.5
