dotnet-performance

Collect a managed CPU trace with dotnet-trace using the dotnet-common and dotnet-sampled-thread-time profiles, then analyze inclusive and exclusive stack costs. Correlate with dotnet-counters and platform-native tools like perf or xctrace when native frames matter.

Build a memory ownership ledger comparing managed live bytes, GC committed heap, RSS/PSS, native allocator growth, mappings, and GPU residency. Escalate to native heap tools like heaptrack or platform VM tools when private memory grows while managed bytes stay flat.

The cpu-sampling profile was removed from standard dotnet-trace collect; use dotnet-common with dotnet-sampled-thread-time instead. It remains valid only for the separate Linux collect-linux perf-based workflow.

A microbenchmark improvement alone does not prove application improvement. Validate with equivalent before/after runs of the real workload, reporting median, spread, and tail metrics rather than a single best run.

Use bounded or triggered collection through dotnet-monitor and diagnostic ports, record cgroup limits and container constraints, and protect secrets in dumps and traces. Keep collection duration and artifact sizes explicitly limited.

High GPU utilization can coexist with acceptable frame times or reflect compositor and driver work rather than shader cost. Classify the bottleneck by correlating CPU submission time, GPU timestamps, queue gaps, and present timing before optimizing.