Runtime profiling and optional eBPF

Profiling explains behavior under a specific workload; it does not replace reproduction or prove a performance improvement. Start from a measured symptom, profile the relevant process while representative load is active, then validate any code change with the same benchmark.

Select the least invasive useful profiler

Inspect runtime, build symbols, existing observability, and the measured symptom. Choose application/runtime profiling (for example Go pprof, Rust samply/perf, Node CPU profiles, or a BEAM-appropriate profiler) before kernel profiling when it can answer the question. Consider CPU, allocation/heap, lock/block, scheduler, syscall, and I/O views based on evidence; do not collect every profile by default. Keep debug symbols and build flags comparable across candidates.