Profiling¶
"A profile shows you where time and memory actually go — which is almost never where you'd guess."
This section is the diagnostic half of Performance — the tooling and reading-skills that turn a vague "it's slow" into a specific "this function allocates 80% of the heap on the hot path."
The four sub-sections cover the four most common profile shapes:
| # | Sub-section | What it measures |
|---|---|---|
| 01 | CPU Profiling | Wall-clock vs CPU time per function; on-CPU sampling profilers |
| 02 | Memory Profiling | Heap snapshots, retained sets, leak detection |
| 03 | Allocation Profiling | Allocation rate and call-sites — distinct from "what's resident" |
| 04 | Flame Graphs | The visualisation that made profile reading tractable; how to read one without lying to yourself |
Why split CPU / Memory / Allocation¶
A common mistake: "profile memory" and look at heap usage. But high allocation rate can wreck GC pause times even when the heap stays small. They are different signals captured by different tools — separating them is the first step toward useful profiling.
Related¶
- Benchmarking — controlled comparison; profiling is exploration.
- Memory Optimization — once allocation profile points the finger, this is where you act on it.
- Diagnostics → Diagnostic Endpoints —
/debug/pprofand JFR-style live profile capture. - Language Internals → Memory Management — why allocations are expensive, not just where.