Performance: UtilityAnalyzerBase calls GetSemanticModel for each SyntaxTree

[martin-strecker-sonarsource]

UtilityAnalyzerBase calls Compilation.GetSematicModel(syntaxTree) here

sonar-dotnet/analyzers/src/SonarAnalyzer.Common/Rules/Utilities/UtilityAnalyzerBase.cs

Lines 98 to 100 in f6a6857

	var treeMessages = c.Compilation.SyntaxTrees
	.Where(x => ShouldGenerateMetrics(c, x))
	.Select(x => CreateMessage(x, c.Compilation.GetSemanticModel(x)));

This is such a big performance issue that the Roslyn team wrote an analyzer RS1030 to flag its use. We should consider looking for a better approach as described by the message of that rule:

dotnet/roslyn-analyzers#3114 (comment)

[andrei-epure-sonarsource]

(off-topic from this issue) @martin-strecker-sonarsource from the POV of RS1030, should we use RegisterSemanticModelAction for all our rules?

[martin-strecker-sonarsource]

should we use RegisterSemanticModelAction for all our rules?

Not in general, but we should look for violations of RS1030.

There are some use cases where you have no other option than to call Compilation.GetSemanticModel(SyntaxTree). e.g. if you have an invocation node in the current tree and you get the IMethodSymbol of the invoked method and you call IMethodSymbol.DeclaringSyntaxReferences and you want to query some semantic model based on the syntax found, it might be that the method is defined in another file and therefore another SyntaxTree and you have to call Compilation.GetSemanticModel(SyntaxTree) to get the right SemanticModel. This is what GetSemanticModelOrDefault is for in our codebase.

sonar-dotnet/analyzers/src/SonarAnalyzer.Common/Helpers/SemanticModelHelper.cs

Lines 25 to 36 in 543953b

	public static SemanticModel GetSemanticModelOrDefault(this SyntaxTree syntaxTree, SemanticModel model)
	{
	// See https://github.com/dotnet/roslyn/issues/18730
	if (syntaxTree == model.SyntaxTree)
	{
	return model;
	}
	return model.Compilation.ContainsSyntaxTree(syntaxTree)
	? model.Compilation.GetSemanticModel(syntaxTree)
	: null;
	}

[martin-strecker-sonarsource]

should we use RegisterSemanticModelAction for all our rules?

We should definitely think about some RegisterSyntaxTree analyzer. If we call the semanticModel in 99% of the cases for such a rule, we are better off with using RegisterSemanticModel instead. The reason is that "SyntxTreeAction" gets called right after the AST is produced. Then the compiler does in parallel the binding (which takes a long time). If you call the semanticModel, you will have to wait until the binding is finished basically blocking the thread.
If we use RegisterSemanticModel in such a case, no blocking occurs because the action is called when the binding is done.

I'm not really sure if the above is exactly right as the documentation doesn't tell about these specifics. The best I could find was this: https://github.com/dotnet/roslyn/blob/main/docs/analyzers/Analyzer%20Actions%20Semantics.md

[pavel-mikula-sonarsource]

On Akka.Net, I did not see any change in performance, the semantic models are most likely cached as they are queried by different rules of the same analysis:
Before: 67s. 65s. 67s
After: 62s, 66s, 69s

[pavel-mikula-sonarsource]

Results for lucenenet - small improvement
Before
1:48
1:29
1:30
1:35
1:34

After
1:47
1:27
1:31
1:28
1:29

[martin-strecker-sonarsource]

Reopened