I started noticing this a few hours back, but a kotlin project that we were using is taking approximately 4 times the time to complete scanning for SonarCloud. To test if this was part of something we changed on our code base, I tried the scan on a branch from a few days back with the same result. We use the Jenkins Sonar plugin to emulate the environment variables and Sonar runs via Gradle. If this is a server issue on your end, please fix. We had to turn off scanning as build times are double what we usually use.
It may be related to A new start for our Kotlin analyzer for Android developers: more security rules, support ktlint, better code quality rules
3 Likes
Hello,
This is certainly linked to the fact we released a new version of the Kotlin analyzer which gives better results.
We were not expecting any significant performance impact so could you share some data? Does it move from 30 to 120 seconds (which will be still acceptable) or you are talking about minutes/hours?
Thanks
Alex
1 Like
Similar issues on one of our projects running against sonarcloud.
previously it was about 60-70 seconds looking at gradle enterprise scan data
today we are failing due to it seeming to lock up for over 10 minutes at which point circleci kills the job.
Only a single job has gotten through today and it took 11m9s
gradle plugin doesn’t seem to want to enable any verbose logging either so insights are still very low. will keep digging on my end to see what I can find out here.
Hi, Alex,
Thanks for responding to this swiftly. The performance is 4 times slower than its normal, ie 600,000 lines scanned in 6 minutes went to an average of 20-23 minutes. I have noticed > 30 minutes of scan time when re-enabling sonar after a long time in the project, but this situation isn’t that, the builds where from consecutive merges to master. Please reach out if you want more info, I’d like to get this sorted out pretty fast.
Thanks,
George
Hello,
I’m coming back to you guys with some news. I did a mistake when I announced our new Kotlin analyzer release. I should have mentioned that the analysis will take more time than before … simply because we provide a deeper analysis than before. In the past, we were just looking at the Kotlin syntax and we were not so satisfied about it, now we understand Kotlin code from a semantic point of view.
This comes at cost and I know you won’t be happy to know that the execution timings you have today are the new baselines.
If you want to improve things especially for small projects that were taking 60 seconds before, you should look at increasing the memory allocated to your scan.
From there, we will do our best to improve the analysis time when it makes sense even if today 20-23min for 600K LOC is compliant with the objective we set internally (≤ 20 min for 500k LOC) for initial scan. Definitely this is boring when it comes to analyze a PR where a single file has been changed. On that field we have ideas to improve performance of PR analysis and I hope we will be able to release such improvements in 2021.
Alex
3 Likes
Hello,
A patch has been deployed today on SonarCloud. Can you confirm it helps to get better performance?
Thanks
If some of you still have performance problems while analyzing Kotlin code with Gradle, can you share with me the output (a file) of the following command:
gradle clean build sonarqube --no-build-cache --info
I can create a private discussion channel with whoever needs it in case you want to share such data privately.
From sending in my logs, the response was that the cumulative run time of all the compile processes were longer than the sonar scan time, eventhough those compile times are from parallel threads. The current patch here is setting the following parameters, that halved the build time (though it’s still double the scan time as was before)
sonar.java.binaries=.
sonar.java.libraries=.
To close this thread here is a summary:
- scanning Kotlin code with SonarCloud takes more time today than before and this is because we improved the precision of the rules thanks to a new engine ; this accuracy is having a cost
- there is nothing we can do immediately to improve the situation
- it’s part of our 2021 objectives to make speed a feature so we are actively working to make PR and full scans working faster than ever
- our Kotlin Analyzer is single-threaded
- if you want to get bad results faster, you can but we don’t recommend at all to do that
- the 2 parameters to set to an empty value are:
sonar.java.binaries=
sonar.java.libraries= - don’t put a dot, this doesn’t mean the same thing as empty
- the 2 parameters to set to an empty value are:
Alex
I guess I hit this problem as well but I get an OutOfMemory instead. Following the build:
I tried if it works better with --no-deamon but it does not. The last success was in June, then I did not have any PR for about a month and then it failed first on 2 July and does since then.
What do I need to do?
Hello @robstoll,
Could you please open another thread with your question and provide the build log and a heap dump?
Your problem is most probably not related to this thread.
Regards,
Margarita
@geojakes A new version of the Kotlin analyzer was deployed today and it contains SONARKT-186 which should positively impact the analysis time of larger projects with a large amount of dependencies.
Can you confirm you see better performance?
1 Like
I just tested this out and its 15 minutes without the work around!! This is awesome!! Thank you!! @Alexandre_Gigleux
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.