.NET Profiling

Trigger On

• the repo needs performance or runtime profiling for a .NET application
• the user asks about slow code, high CPU, GC pressure, allocation growth, exception storms, lock contention, or startup diagnostics
• the team wants official CLI-based diagnostics without depending on dnx

Workflow

1. Build and run a realistic target first:

- prefer Release - prefer realistic config, inputs, and data volume

1. Start with the lightest useful tool:

- dotnet-counters for live health signals - dotnet-trace for CPU, exception, contention, GC, and startup traces - dotnet-gcdump for managed heap inspection when memory shape matters

1. Prefer installed CLI tools over dnx one-shot execution so the repo commands stay stable and reproducible.
2. Capture one focused profile at a time instead of mixing every signal into one run.
3. For CPU and general runtime hotspots, start with dotnet-trace collect.
4. For live triage, start with dotnet-counters monitor on System.Runtime.
5. For heap analysis, use dotnet-gcdump carefully and document the pause risk.
6. After each change, rerun the same measurement path and compare before versus after.

Deliver

• explicit official .NET profiling commands
• a clear profiling path for CPU, counters, and heap inspection
• reproducible diagnostics commands that humans and agents can rerun

Validate

• the chosen tool matches the actual symptom
• commands target a realistic process and configuration
• before/after comparisons use the same scenario
• heap collection warnings are explicit when dotnet-gcdump is used

Load References

Related skills

Related agents