Topic: profiling
-
Continuous profiling in production: always-on sampling profiles and what they answer
Continuous profiling takes CPU and memory profiles systematically over time and stores them as labelled series, so a team can ask which function consumed the most CPU across the fleet yesterday or what changed between two versions; sampling profilers make it cheap enough to leave on, and runtime endpoints such as Go's /debug/pprof/ or eBPF agents supply the profiles.
-
Reading a flame graph: width is samples, the x-axis is not time
A flame graph stacks sampled call stacks so that frame width is the share of samples and height is stack depth; the x-axis is sorted alphabetically, not by time. Read wide plateaus at the top as on-CPU hot spots, wide frames with many thin children as callers to call less often, and remember that a CPU flame graph cannot show waiting.
-
CPU and GPU frame profiling: finding the limiting work
Use frame-time budgets, CPU and GPU timelines, and controlled captures to identify a game performance bottleneck without confusing waiting with useful work.
-
Unity SRP Batcher: optimise CPU preparation without confusing it with instancing
Understand the SRP Batcher’s CPU-side purpose, inspect material and shader compatibility, and measure it separately from GPU instancing.
-
CPU profiling with perf: perf top, perf record -g, perf report, and perf_event_paranoid
perf top gives an immediate live profile; perf record -g saves a call-graph profile to disk for perf report to read later. The kernel's perf_event_paranoid setting controls what an unprivileged user can do, and symbol resolution needs matching debug information for every frame in the stack.
Machine-readable: JSON