Meta analyzer to flag use of Compilation.GetSemanticModel inside diagnostic analyzers

[mavasani]

We have seen tons of performance issues in sub-optimally written analyzers that end up creating completely new semantic models by invoking Compilation.GetSemanticModel. This leads the compiler to rebind the entire file, and doing it multiple times (say with SyntaxNode callbacks) can be a performance hog. For example, #2576 identified this can lead a 4x-5x slowdown. With nullability flow analysis in place inside the compiler, this can be even worse.

We should write an analyzer that flags use of this API inside a diagnostic analyzer. Implementation of this analyzer should potentially be a sub-type of DiagnosticAnalyzerCorrectnessAnalyzer.

[mavasani]

Tagging @Evangelink

[kzu]

So, what is the replacement for an analyzer that actually does need to access symbol info to report accurate diagnostic?

[mavasani]

Diagnostic description in error list, when expanded, should give the info:

roslyn-analyzers/src/Microsoft.CodeAnalysis.Analyzers/Core/CodeAnalysisDiagnosticsResources.resx

Line 395 in 8bc7b0b

<value>'GetSemanticModel' is an expensive method to invoke within a diagnostic analyzer because it creates a completely new semantic model, which does not share compilation data with the compiler or other analyzers. This incurs an additional performance cost during semantic analysis. Instead, consider registering a different analyzer action which allows used of a shared 'SemanticModel', such as 'RegisterOperationAction', 'RegisterSyntaxNodeAction', or 'RegisterSemanticModelAction'.</value>

[mavasani]

In general, it is always better performance wise to switch to RegisterOperationAction for semantic analysis of executable code and RegisterSymbolAction for semantic analysis of symbols and non-executable parts of the code.

[kzu]

Got it. Thanks!