Performance Optimization for .NET

Most .NET performance work goes wrong in the same place: optimising things that were never the bottleneck. Database round trips, N+1 LINQ queries, badly tuned thread pools, and synchronous I/O on async paths cost orders of magnitude more than the micro-optimisations developers reach for first. Performance writing here starts from that premise — measure with BenchmarkDotNet or PerfView, then decide whether the change is worth the readability tax.

That said, modern .NET has shipped a quiet stream of low-level primitives that genuinely move the needle when used in the right place. SearchValues<T> collapses linear scans for character or substring sets into vectorised lookups, and the analyzer rule CA1870 will tell you exactly where to apply it. The throughput difference on hot string-validation paths is not marginal — five-times speedups are routine, and the change is a couple of lines.

CompositeFormat removes the cost of re-parsing the same format string on every call, which matters in logging, response formatting, and template-heavy code. [ConstantExpected] is the API-design counterpart: it lets you mark a parameter as required-constant so callers and analyzers cooperate on letting the JIT specialise. Source generators replace reflection-based serialization or DI registration with code the compiler can inline, but they also tax build times in ways that are easy to overlook until your CI minutes triple.

Allocation patterns deserve their own attention. Span<T>, stack allocation, pooled buffers via ArrayPool<T>, and the LoggerMessage source generator on filtered debug paths all exist to keep the garbage collector out of the hot loop. None of them are free, and none of them help if the real cost is a missing index or a chatty HTTP client. The collection here is deliberately biased toward decisions that survive contact with profiling data rather than coding-style preferences with performance branding.