You’ve resurrected a topic that’s 1 year old. Per the FAQ, please don’t do that.
I’ve moved your post to a new thread. Can you please flesh out the details like your context for this? I.e. are you on SonarQube Cloud? SonarQube for IDE (flavor and version)? SonarQube self-managed (flavor and version)?
Can you provide a full analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
Hi @bmarotta-ease, I took a look at the logs. The engine takes about 3 minutes to analyze ~25k NCLOC, which falls within our performance targets.
I believe the confusion comes from the following part:
The engine hangs on a very small index.ts file (29 lines). […]. It is not acceptable that our pipeline spends 80% of its time scanning 1 file.
Unfortunately, analysis time does not necessarily scale linearly with the number of lines of code. Looking at the file names, it seems to be a React application. It is expected that most of the analysis time is spent on index.ts because it is likely the place where everything fits together. This is where the engine simulates all the complex interactions between hooks and components, which can only be done once the engine has created an abstract model of your application.
Thanks for your answer. I must disagree with 2 points.
First, you stated that the engine takes about 3 minutes, which is not correct. You can see in the logs:
10:50:42.960 DEBUG Scanner status reported
10:50:42.992 INFO Analysis total time: 5:09.880 s
So it takes 5 minutes and not 3. I’m not sure where you got the 3 minutes from. And according to your performance targets, 100k LOC should take <= 5 minutes, not 25k.
Second, the performance targets also states that the code change analysis should be proportional to the change set. That’s not what we observe. We see that all analysis (master branch, PR merge or feature branch) take around 5 minutes.
Is it something that we need to change in our configuration?
Another disturbing fact is that we are already using a docker machine with bigger memory than all the other pipelines and the analysis seems to be hitting 100% memory. Should we increase the memory even more? What is the suggested memory for analysing a React app?
The 3-minute figure I mentioned comes specifically from the JsSecuritySensorV2 (the JS/TS security analysis), which drives the bulk of the analysis time.
However, you are right that the total time includes other components. Specifically, the standard JS sensor (for bug and code smell detection) takes another ~30 seconds. The remaining time is non-plugin overhead (file indexing, downloading quality profiles, loading rules, …).
Second, the performance targets also states that the code change analysis should be proportional to the change set.
As stated on that documentation page, while this is our target, it does not currently apply to all languages. JavaScript and TypeScript are explicitly listed there under “next steps”. Delivering this incremental analysis for JS/TS is a primary focus for our team this year.
What is the suggested memory for analysing a React app?
This is highly application-dependent, so we do not have a specific baseline suggestion. Since you are hitting 100% memory usage, you should try increasing the allocation to see if performance improves.
Anyway, if you are willing to share your source code (or even better, a small reproducer) we can take a closer look to see whether we can improve the engine’s memory usage for your setup. Let me know if you’d like me to open a private thread for you to share those files securely.