microbenchmarking

Create, run, and configure BenchmarkDotNet microbenchmarks for .NET performance measurement.

Updated Jul 12, 2026
One-click install
npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill microbenchmarking-patrick-rex
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: microbenchmarking
Source: https://github.com/Patrick-Rex/DotNetTechSamples/tree/main/.agents/plugins/dotnet-diag/skills/microbenchmarking
Command: npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill microbenchmarking-patrick-rex

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing correct BenchmarkDotNet benchmarks is error-prone: outdated assumptions about job configuration, runtime comparison, and execution defaults silently produce misleading measurements. This Skill provides verified, current guidance for designing, configuring, running, and comparing .NET microbenchmarks so results are trustworthy. ## Core Features & Use Cases - Benchmark authoring guidance: Covers dead code elimination, constant folding, setup/cleanup patterns, parameterization ([Params], [Arguments], [GenericTypeArguments]), async benchmarks, and deferred execution pitfalls. - Comparison strategies: Side-by-side methods, runtime comparison (net8.0 vs net9.0), NuGet package version comparison, saved-DLL baselines, GC/JIT configuration comparison, and input-scale analysis with ratio columns. - Execution and cost control: Job presets (Dry, Short, Default, Medium, Long), CLI filtering, output redirection, and case-count estimation to keep benchmark runs within time budgets. - Diagnostics and export: MemoryDiagnoser, DisassemblyDiagnoser, EventPipeProfiler, hardware counters, statistical columns, and JSON/CSV/Markdown exporters. - Use Case: A developer wants to verify that a new parsing implementation is faster than the old one. The Skill guides creating a standalone benchmark project, marking a baseline method, validating with a Dry run, and producing a side-by-side ratio table. ## Quick Start Ask the AI to create a BenchmarkDotNet benchmark comparing two implementations of a .NET method and run it with a Dry job to validate before measuring.

Frequently Asked Questions about microbenchmarking

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a BenchmarkDotNet benchmark in .NET?

Create a console project, add the BenchmarkDotNet package with dotnet add package, and use BenchmarkSwitcher.FromAssembly(...).Run(args) as the entry point. Return values from benchmark methods, move initialization to [GlobalSetup], and validate with --job Dry before full runs.

How do I compare two implementations with BenchmarkDotNet?

Define both implementations as benchmark methods in the same class and mark one with [Benchmark(Baseline = true)]. BenchmarkDotNet then adds Ratio columns showing each method's mean relative to the baseline in a single run.

How do I compare benchmark results across .NET runtime versions?

Use <TargetFrameworks>net8.0;net9.0</TargetFrameworks> in the csproj and run with --runtimes net8.0 net9.0. Each runtime becomes a separate job, and the first runtime listed is treated as the baseline for ratio columns.

Why does my BenchmarkDotNet benchmark measure nothing or give wrong results?

Common causes are dead code elimination from void returns, constant folding from literal inputs, setup code inside the benchmark method, and manual loops. Return results, store inputs in fields or [Params], and let BDN control invocation counts.

When should I not use BenchmarkDotNet?

Do not use it for profiling or tracing .NET code (use dotnet-trace or PerfView), production telemetry, or load and stress testing (use Crank or k6). BenchmarkDotNet is designed for controlled microbenchmark measurement, not production observation.

How long do BenchmarkDotNet runs take and how do I speed them up?

Each benchmark case takes 15-25 seconds with default settings, and [Params] multiplies cases via Cartesian product. Use --job Dry for validation, --job Short during development, and --filter to run subsets of methods per invocation.