CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

dotnet-inspect-performance

Find high-leverage .NET methods with allocation and repetition evidence, trace candidate costs through calls and IL, and select focused profiling or benchmark follow-ups rather than claiming measured wins.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/performance/SKILL.md
SKILL.md
Quality
Evals
Security

dotnet-inspect: Find .NET Performance Optimization Candidates

Use this skill to find Members worth investigating, not to infer measured wins. Run dnx dotnet-inspect -y -- <command>. This static analysis is experimental; use installed discovery for current shapes, fields and query rules.

Start with leverage and actionable candidates

dnx dotnet-inspect -y -- library MyLib.dll -S "Top Leverage"
dnx dotnet-inspect -y -- library MyLib.dll -S "Performance:*" \
  --where "Priority>=high" --top 20 --tsv
dnx dotnet-inspect -y -- library -D @Performance
dnx dotnet-inspect -y -- library -Q "Performance: Arrays" --json

Top Leverage ranks call-graph reach, not execution frequency. Intersect its Members with performance candidates to choose a focused drill. A large call-graph footprint can matter even when a local cost is small.

Library triage has kind-scoped sections; Type/Member scope uses Performance Triage. Use --all for non-public Type/Member targets. --top selects a curated ranked prefix, while -n/--rows shape output; they are not interchangeable. @Performance includes heterogeneous sections, so use concrete sections or Performance:* for compatible row output.

Keep priority, confidence and runtime cost separate

  • Priority is static actionability, not measured hotness.
  • Confidence describes evidence/rewrite certainty, not importance.
  • A potential allocation is not guaranteed bytes or frequency.
  • Repetition in a local or caller loop does not prove that the loop executes often, and recursive structure does not prove realized depth.
  • Async state-machine allocation can be amortized; it is not automatically an avoidable per-item cost.

Focus first on IL-visible costs such as boxing, arrays, delegates and materialization. Do not prescribe rewrites for work the JIT may remove without runtime evidence. A scan-in-loop candidate needs evidence that the scanned population grows; a small-array candidate needs escape/lifetime evidence before recommending stack allocation.

For an unfamiliar shape, use explain "<question>" and follow its returned resource and binding. Use -Q before constructing predicates or field orders; displayed fields do not automatically support either.

Drill one exact Member

dnx dotnet-inspect -y -- member MyType Method:1 --library MyLib.dll \
  -S "Performance Triage" --json
dnx dotnet-inspect -y -- member MyType Method:1 --library MyLib.dll \
  -S "Call Graph" --fields "Alloc,Loop" --tree
dnx dotnet-inspect -y -- member MyType Method:1 --library MyLib.dll \
  -S "Annotated Source,IL" --offline

Choose a copyable stable selector from the inventory rather than inferring one from a formatted label. Retain Candidate, Finding, provenance and physical Member/IL coordinates. Exact, aggregate and unmatched provenance are different claims: an aggregate candidate is not an exact allocation occurrence. Generated async bodies may own the physical IL receipt even when the displayed Member is the source-facing method.

Follow calls toward public entrypoints and callers, then inspect the local operation. A function load or callback registration does not establish invocation. Source or IL explains the candidate; a representative benchmark, allocation trace or profiler establishes runtime cost and rewrite benefit.

Call Graph machine rows are available through --jsonl/--tsv; a separate Member Share URL opens its public API Overview, not this performance lens.

Broader investigations

QuestionEntrance
How much implementation is concentrated in a few Members?library MyLib.dll -S "Library Metrics"
Where do allocations fan out through construction paths?library MyLib.dll --triage-shape allocation-fanout --top 20 --tsv
Which costs repeat through caller loops?library MyLib.dll -S "Performance:*" --where "CallerLoop=direct" --json
Does pooled-resource cleanup deserve attention?library MyLib.dll -S "Resource Triage" --jsonl
When did one allocation appear?diff --history --package MyLib@old..new -t MyType -m Method --finding analysis.allocation --at first --at last

Pool churn on exception paths is a hardening/profiling candidate, not a proven permanent leak or memory-corruption finding. Resource Triage has no positive completion receipt: describe pooled-resource coverage as unverified, even when rows are present. Load skill correctness for ownership interpretation.

History checkpoints locate a window, not exact onset. Confirm the adjacent pair with diff --package MyLib@old..new -t MyType -m Method --finding analysis.allocation; a native Added occurrence establishes introduction, unlike an aggregate count delta. Load skill compatibility for the search policy and boundary interpretation.

Stop when each pursued candidate is confirmed, dismissed or explicitly open. Report static observations separately from measured cost, proposed rewrites and unverified coverage.

Repository

richlander/dotnet-inspect

Path

skills/performance/SKILL.md

Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.