dotnet-asynkron-profiler

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
4. Choose exactly one primary mode first:
   • --cpu
   • --memory
   • --exception
   • --contention
   • --heap
5. Use --input <path> when the trace already exists and the task is about rendering or narrowing the report, not recollecting data.
6. 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
7. Treat profile-output/ as the stable output folder for review artifacts and reruns.
8. If the task needs process attach, counters, or raw official diagnostics flows rather than this CLI frontend, hand off to dotnet-profiling.

Architecture

flowchart LR
  A["Profiling task"] --> B{"New run or existing artifact?"}
  B -->|New run| C["Build target in Release"]
  C --> D["Run `asynkron-profiler --mode -- <command|csproj|sln>`"]
  D --> E["Collect via `dotnet-trace` or `dotnet-gcdump`"]
  E --> F["Write reports to `profile-output/`"]
  B -->|Existing artifact| G["Run `asynkron-profiler --input <path> [--mode]`"]
  G --> F
  F --> H["Refine output with `--root`, `--filter`, and call tree flags"]