Asynkron.Profiler

Trigger On

• the repo wants Asynkron.Profiler or asynkron-profiler
• the user wants automation-friendly profiling output instead of GUI-only tooling
• profiling needs are CPU, allocation, exception, contention, or heap focused and should land as plain-text summaries in CI, scripts, or agent workflows
• the task needs to render an existing .nettrace, .speedscope.json, .etlx, or .gcdump file into a readable report

Workflow

1. Decide whether the task is a new profile capture or rendering an existing trace artifact.
2. Prefer built Release output over dotnet run so the trace represents the target app rather than restore/build noise.
3. Install and verify all three tools before assuming the profiler is usable:

- asynkron-profiler - dotnet-trace - dotnet-gcdump

1. Choose exactly one primary mode first:

- --cpu - --memory - --exception - --contention - --heap

1. Use --input <path> when the trace already exists and the task is about rendering or narrowing the report, not recollecting data.
2. Refine the output only after the baseline run:

- --root <text> to anchor the call tree - --filter <text> to trim tables - --exception-type <text> for exception-heavy flows - --calltree-depth, --calltree-width, --calltree-self, --calltree-sibling-cutoff

1. Treat profile-output/ as the stable output folder for review artifacts and reruns.
2. If the task needs process attach, counters, or raw official diagnostics flows rather than this CLI frontend, hand off to dotnet-profiling.

Deliver

• a repeatable asynkron-profiler command path for the profiling mode that matches the problem
• explicit install and prerequisite commands
• a clear baseline command plus any focused --root, --filter, --exception-type, or call-tree options needed for readable output
• trace replay guidance when the task starts from an existing artifact

Validate

• asynkron-profiler --help, dotnet-trace --version, and dotnet-gcdump --version all succeed
• the chosen profiling mode matches the question being investigated
• the command profiles built Release output unless there is a documented reason to accept dotnet run noise
• profile-output/ contains the expected report or artifact after the run
• any replay flow uses an input file type that matches the selected mode

References

Related skills