dotnet-micro-optimization

Benchmarks and optimizes hot functions using hypothesis-driven variants and disassembly analysis.

2|1|Updated May 11, 2019
One-click install
npx skills add https://github.com/guitarrapc/dotfiles-win --skill dotnet-micro-optimization-guitarrapc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-micro-optimization
Source: https://github.com/guitarrapc/dotfiles-win/tree/main/HOME/.agents/skills/dotnet-micro-optimization
Command: npx skills add https://github.com/guitarrapc/dotfiles-win --skill dotnet-micro-optimization-guitarrapc

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Optimizing a small hot function often devolves into guesswork: plausible ideas get shipped unmeasured, and roughly a third of well-reasoned optimization hypotheses turn out to be wrong. This Skill provides a disciplined, benchmark-driven loop that finds the fastest implementation of a hot function by testing one hypothesis per variant, gating on correctness, and explaining results with JIT/native disassembly. ## Core Features & Use Cases - Hypothesis-driven variant benchmarking: Build a BenchmarkDotNet (or criterion/google-benchmark) harness where each variant changes exactly one thing, with a correctness gate that compares every variant against the baseline across sizes, seeds, and edge inputs. - Disassembly-guided analysis: Read JIT disassembly to explain why numbers differ — bounds checks, inlining failures, register spills, static-init guards — and follow a prioritized hypothesis ladder from algorithmic waste removal through SIMD vectorization to domain instructions like GFNI and PCLMUL. - Convergence audit and shipping: Run mechanical audits (loop-invariant arguments, size cliffs, serial-recurrence SIMD re-checks) before declaring done, then ship the winner with tiered runtime dispatch, parity tests, and honest before/after end-to-end measurements. - Use Case: A developer suspects a CRC or encoding kernel is slow. The Skill guides them to copy it into a self-contained benchmark, test variants like table lookups and AVX2 vectorization, keep a findings log of confirmed and refuted hypotheses, and port the 2x winner back with capability-gated dispatch. ## Quick Start Ask the AI to set up a micro-benchmark loop for your hot function and iterate on optimization variants until improvements fall below 2-3%.

Frequently Asked Questions about dotnet-micro-optimization

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

FAQPage Schema
How do I benchmark and optimize a hot function in C#?

Copy the function into a self-contained BenchmarkDotNet project, create a baseline variant plus one variant per hypothesis, and gate all variants on correctness against the baseline. Run with warmup and 15 iterations, compare ratios within a single run, and use DisassemblyDiagnoser output to explain the numbers.

What is the best way to compare implementation variants with BenchmarkDotNet?

Change exactly one thing per variant relative to a named parent and document the hypothesis in a comment. Compare ratios only within the same run, since cross-run drift from code layout is plus or minus 5-10%, and treat differences under 2-3% as noise.

Does BenchmarkDotNet support disassembly and memory diagnostics?

Yes, BenchmarkDotNet supports MemoryDiagnoser for allocation tracking and DisassemblyDiagnoser for per-benchmark JIT disassembly with source annotation. Configure them in a ManualConfig with warmup count 3 and iteration count 15 for statistically meaningful nanosecond-scale results.

When should I not use micro-optimization on a function?

Do not micro-optimize when the bottleneck is unknown (profile end-to-end first) or when an algorithmic improvement is still available, since a better algorithm invalidates all constant-level tuning. Also estimate the ceiling first: a function using X% of total time can yield at most X% end-to-end gain.

Why is my SIMD vectorized code slower than the scalar version?

Wider vectors are not automatically faster; measure 128-bit versus 256-bit widths, since wider vectors can lose on some CPUs. Also check for serial dependency chains, register spills, and per-call setup costs in the disassembly, which can erase vectorization gains on small inputs.

How do I ship SIMD-optimized code with runtime dispatch in .NET?

Use tiered dispatch with IsSupported checks: newest-ISA kernel first, then common-SIMD, then a portable scalar fallback, with compile-time TFM gates where APIs are unavailable downlevel. Add parity tests comparing each kernel against a naive reference across sizes, seeds, and edge inputs.