Use when something is slower than it should be - a test suite, a build, a compile, a service, a batch job - when adding threads or machines stops helping, when CPU sits idle while work waits, or before any optimization at all. Measure first, then find the mechanism; a scaling curve, a processes-versus-threads split and stack sampling locate the bottleneck, decompiling or reading the library confirms why, a behavior-neutral differential proves the fix changed nothing, and a structural guard (never a wall-clock limit) keeps it fixed. Not for micro-benchmarking one method in isolation (see dotnet-engineering's BenchmarkDotNet rules) or for code review of performance smells (…
