FindBug and SQUID sensor used / performance

[matad...@googlemail.com]

Team,

I noticed we have a large amount of time for both the Java SQUID sensor and find bugs in a particular module i.e.

[INFO] Sensor JavaSquidSensor (done) | time=572295ms
[INFO] Sensor FindBugs Sensor (done) | time=370841ms

A few points

1) Is this simply because we maybe running some deprecated rules now which are already covered by SQUID? As far as you're aware are all rules replaced or are there still some required in find bugs? If we deprecate find bugs rules but leave some in as required will that time usually decrease or does it usually stay constant if find bugs has to process even one rule?

2) Is there anyway to break down the SQUID sensor time further e.g. perhaps a sub set of rules are actually taking the majority of the time to analyse?

Normally I wouldn't be so concerned with performance as our nightly job runs fine however we're looking at using the sonar stash plug in to perform analysis for each developer in their pull request

Thanks

[Nicolas Peru]

Hi, 

Could you specify a bit your context ? 

How many files are analyzed ? Which version of SQ and java plugin are you using ? 

How large is the classpath provided to the analyzer ? 

It is nearly impossible to answer your question properly without knowing more about what's going on with your analysis.

While yes, number of rules may have an impact of performance and eventually one rule may have some troubles so reducing rules should improve speed this is most probably not the best course of action to investigate a performance issue. 

However : I would be very interested to understand which rules from findbugs you are still using in your analysis that could not be covered in the java analyzer ? (that would help us improve the java analyzer and you could in the end remove the findbugs plugin alltogether). But for that, please specify the java analyzer version.

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4300815e-032b-4942-98d2-7a31a9c33b02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[matad...@googlemail.com]

Thanks Nicholas,

Sorry I should have added these details initially. 

1) SonarQube 5.6.0 LTS

2) FindBugs plug in 3.4.3 

3) Java 4.2 plug in

4) We have approximately 2500 files.

5) Class path - We use standard maven poms to build and analyse using the sonar post build action. Is there a way to see in the logs the size of the class path easily? I wouldn't think it would be that large other than the maven dependencies in the pom.xml 

6) I'm not sure on the best way to identify all find bugs in our profile however if I compare the findbugs default quality profile with our custom profile ( using sonar way initially and then overridden ) we see many rules that are in both our profile and find bugs.  Is there a way to search by a find bugs tag as I couldn't see one?

[Nicolas Peru]

Hi, 

In order to provide more information you can use sonar.showProfiling=true see :  http://docs.sonarqube.org/display/SONAR/Analysis+Parameters#AnalysisParameters-AnalysisLogging

That might give you a breakdown of where the time is spent in the java analyzer. 

But with 2500 files and given the time I am not really sure you can expect a huge breakthrough from this information. 

So in order to improve perf, please investigate to find a bottleneck and fix it first. But one course of action would be to try to remove Findbugs alltogether to save its analysis time because there should not be anything findbugs does that the squid analyser is not able to do (Disclaimer I am a bit biaised here). 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8262be2a-f015-4422-b2af-2f93305456d1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[matad...@googlemail.com]

Thanks Nicolas,

I would actually like to see if we can remove find bugs altogether however I can't see an easy way in Sonar to

1) Find all the "findbugs" only rules in our profile

2) For each find bug rule find the SQUID replacement e.g. from a mapping. 

Wouldn't it be nice to have a report / list of rules you could simply disable in bulk and then enable the SQUID equivalents. We could then run a test analysis with these changes to view the violation changes. If they looked fine we could then apply the same profile set to production

Also the option sonar.showProfiling=true only created a simple high level file in .sonar / profiling with high level timings.  Is there a way to get more detailed breakdowns of individual file parsing times? 

[G. Ann Campbell]

Hi,

I think this is what you're looking for: http://dist.sonarsource.com/reports/coverage/findbugs.html

Ann

[Nicolas Peru]

Hi, 

There is currently no possibility to drill down the profiling from the logs.

Fire up a profiler to do so. 

Cheers,  

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/2fb21189-2627-42e0-95ff-7e236dfb7775%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[matad...@googlemail.com]

Thanks Ann, however I meant the ability within the Sonar UI to make this easier e.g. using the rule search filter

[matad...@googlemail.com]

Sure thanks Nicolas. Also I was wondering if there is any multi threaded parsing in the sensor e.g. each file should be quite isolated in many cases to do this

[Nicolas Peru]

Hi, 

Currently no. It could be easily implemented because parsing and analysis is file isolated and it was done as an experiment by Duarte (Sonar Scanner team dev) but this does not speed things up a lot and might be counterproductive to the direction we may take in the near future to share resuts of analysis between files.

Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/d0e4eec6-c6ca-4ae6-84a4-1c9a428fe066%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[matad...@googlemail.com]

Thanks Nicholas,

Yes that might be better although having control over whether multi threaded parsing could be utilised as a configurable could be useful for clients. 

Back to the find bugs / SQUID points I actually tried a test profile wth only pure SQUID Java rules added.  I didn't expect to see the FindBugs sensor still being used though is this normal? 

08:15:01 [INFO] Sensor JavaSquidSensor (wrapped) (done) | time=545285ms

08:15:01 [INFO] Sensor SCM Sensor (wrapped)
08:15:01 [INFO] Sensor SCM Sensor (wrapped) (done) | time=157ms
08:15:01 [INFO] Sensor FindBugs Sensor (wrapped)
08:15:03 [INFO] Findbugs output report: /var/jenkins/workspace/Sonar_Sbx_Stash/source/test-app/target/sonar/findbugs-result.xml
08:17:26 [INFO] Sensor FindBugs Sensor (wrapped) (done) | time=145121ms

Isn't it odd to be taking 2.5 minutes when it shouldn't be doing nothing or not even called?

Many thanks

[matad...@googlemail.com]

Also perhaps unrelated but even when using sonar.inclusions in the same project for two java files we see the find bugs sensor used and also not appearing to honour the sonar.inclusions 

[INFO]  * Sensors execution time breakdown:                          3min 59s
[INFO]    o FindBugs Sensor:                                         3min 38s (91%)
[INFO]    o JavaSquidSensor:                                              18s (7%)
[INFO]    o JaCoCoSensor:                                                  1s (0%)
[INFO]    o JaCoCoOverallSensor:                                        866ms (0%)
[INFO]    o SurefireSensor:                                             414ms (0%)
[INFO]    o CPD Block Indexer:                                          198ms (0%)
[INFO]    o Zero Coverage Sensor:                                        45ms (0%)
[INFO]    o Lines Sensor:                                                19ms (0%)
[INFO]    o Code Colorizer Sensor:                                        1ms (0%)
[INFO]    o JaCoCoItSensor:                                               1ms (0%)

[matad...@googlemail.com]

Ok some more progress. I found an issue reported that the find bugs plug in 3.4.3 does not honour the profile to see if at least one active rule is present. 3.4.4 isn't available on the update center so after manually download the jar and uploading I still see a similar issue

[INFO] Sensor FindBugs Sensor
[INFO] Loading findbugs plugin: /var/jenkins/workspace/Sonar_Sbx_Stash/source/test-app/target/sonar/findbugs/findsecbugs-plugin.jar

[INFO] Findbugs output report: /var/jenkins/workspace/Sonar_Sbx_Stash/source/test-app/target/sonar/findbugs-result.xml

[INFO] Sensor FindBugs Sensor (done) | time=351338ms

Is it the FindBugs sensor causing this time or some working in the findsecbugs-plugin.jar? I couldn't even find this plug in in the extensions folder and presume it's part of the sonar-findbugs plug in. My quality profile certainly contains only Java rules from the Java repository 377 to be exact. I'd love to remove the 351 seconds from findbugs time here

[matad...@googlemail.com]

An old thread however I realise I didn't get a follow up answer here. Appreciate if you can help. 

Also in relation to Ann's earlier link

http://dist.sonarsource.com/reports/coverage/findbugs.html

What is the meaning of the "rejected" find bug issues? Does this mean you won't implement them in SQUID so I should simply remove in our current profile? I couldn't see any reason against each one other than it was in a rejected list

Thanks

[Nicolas Peru]

Hi, 

rereading the thread I can't really figure out what is exactly your issue and therefore how we could imagine helping you out. Please state your problem clearly.

As this thread is fairly old : can you please state again what are the versions of analyzers and SonarQube you are using ? thanks. 

As per rejected findbugs rules : this is just some rules we thought were not valuable enough or not precise enough to be worth reimplementing. 

Cheers, 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/769d5fd3-e84d-4502-9fa7-029bcf6a2709%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Nicolas Peru | SonarSource

Senior Developer

http://twitter.com/benzonico

http://sonarsource.com