Help Figuring Out .NET Project Scan Taking Significantly Longer

Hi,

Thanks for the response. I think there might’ve been some performance improvements in the DE version since 7.8. Please do upgrade if you can & report back.

 
Ann

I will be able to test this Monday morning. Thank you for the response, and I will try to keep responses timely.

Tyler

1 Like

Updated to 7.13 (build 8313) and there is no difference in the scan length. It seems to have identified less issues, so i suppose that could lead to a smaller average time, but the build still took nearly 22 minutes.

Tyler

Hi @trgabriel ! Given that you are using SQ LTS (6.7.5), you don’t have the injection rules (they’ve been added in SQ 7.2, in a separate plugin than the C# plugin), so the problem probably lies somewhere else.

Could you please provide the verbose logs for the build step and the scanner end step (docs here)?

1 Like

Do you have somewhere I can post the logs?

Sent log files through direct message.

1 Like

Thanks, I looked at the logs and didn’t find anything suspicious. One suggestion is to modify the logging only at error level, and by doing this you will probably gain some minutes - all Roslyn analysis messages are warnings (this is out of our control) - hence the huge log files.

I would have to profile the analysis to see if there are certain rules that take up the time, but for that I would need the source code. Please try keeping the log level at error and see what the perf increase is.

1 Like

What setting needs to be changed to reduce the log levels? Is this at the build level or at the sonarqube level?

I’m referring to the build logs. Roslyn analyzers run during build. See MSBuild Command-Line

1 Like

I saw a decrease of roughly a 30-60 seconds but that is also a small enough difference that it could just be an outlier. The dev team has also let me know that they would not want to do this as a long term solution for this problem.

Indeed, it’s not much gain.

One idea would be to disable the rules that are based on Symbolic Execution and we know they are more costly. These rules are S1944,S2259,S2583,S2589,S3655,S3900,S3966,S4158.

Another way to gain more insight in which rules are eating up the time is to use the -reportAnalyzer MSBuild option, and then disable the greedy rules for your project…

msbuild /p:reportanalyzer=true /v:d

If you run the build with reportanalyzer, please share the results with us :slight_smile: In the medium term, we want to gather more metrics on the performance of our rules, any help counts.

2 Likes

Disabling the rules described above resulted in a build time of 19:47. Roughly a 2 minute reduction. Will need to talk to the team if the rules disabled are worth the two minutes. Attempting to run the reportAnalyzer results now. Will send the results in a direct message if successful. I may need to push this back until Monday.

I tried adding both:
msbuildArgs: ‘-reportAnalyzer:True’
and
msbuildArgs: ‘-ReportAnalyzer:True’
to the VSBuild azure dev ops task, and neither worked. Do you know what I am doing wrong?

You need to pass the arguments the same way you would for the command line i.e.

image

So I believe that worked, but how do I read the results?

The results are part of the MSBuild output. Search the log output for the step for the text Total analyzer execution time:. There will be one set of results for each MSBuild project.

1 Like

This seems to be the main slowdown.

Total analyzer execution time: 893.913 seconds.
NOTE: Elapsed time may be less than analyzer execution time because analyzers can run concurrently.
Time (s) % Analyzer
893.913 100 SonarAnalyzer.CSharp, Version=7.13.0.0, Culture=neutral, PublicKeyToken=c5b62af9de6d7244
448.313 50 SonarAnalyzer.Rules.CSharp.TokenTypeAnalyzer
445.228 49 SonarAnalyzer.Rules.CSharp.SymbolReferenceAnalyzer

What rules do these correspond to? Also, who should I send the metrics of the rule performance to? I will just cut out all of the similar blocks of text as what I pasted above.

Could you send them to @Andrei_Epure as before please? Thanks.

Interesting. Those analyzers don’t correspond to “real” rules, unfortunately, so I don’t think they can be disabled directly. They’re used to generate the metadata required for syntax and reference highlighting when browsing the code on SonarQube/SonarCloud.

I’m surprised they take so long because they don’t do anything complicated. Could you give us a rough idea of the number of lines of code in your solution please?

It appears to be a Test project. We don’t have an exact line count, but we believe it is around 5-10k lines of code. We made some changes to exclude it from the analysis, and this brought the scan down to 7-8 minutes. I think we can say that this is fixed unless you want to try to dig deeper into the cause of the slow down.

1 Like

I am glad you found a solution to the problem. I will try to find out if this behavior (TokenTypeAnalyzer taking lots of time) is consistent over the open source projects we analyze on a daily basis.