Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1121

When analysing a project on SonarCloud for the first time we might believe the process is frozen





      As a new SonarCloud user, when analyzing a very basic project for the first time, the analysis might take several minutes and nothing is displayed to understand what happens. As a consequence, this first time user experience is really bad and might even lead the user to believe that something is unexpectedly frozen.

      The reasons are pretty simple:

      • About 100MB must be downloaded from SonarCloud when launching an analysis on a machine for the first time.
      • If the local internet bandwith is limited to 1 MB, 1 minute and 40s of "freeze" is required before really launching the analysis of the source files. During this period of time nothing is displayed to show that something is "in progress".


      Two complementary actions should be initiated to fix this UX issue:

      • Whatever is the time required to download everything, a progress status bar must be displayed and updated each X seconds. PS: We already know that displaying and updating this status bar might not be possible with Gradle.
      • Then we should dream about dividing the size of all downloaded artefacts by 10 and so to download a maximum of 10 MB (10s is required to download 10MB with an internet bandwith of 1MB).


      To reduce the size of the downloaded artefacts the followings first improvements could be done:

      • The size of the scanner engine is 25MB and at least 10MB can easily be removed by dropping the backward compatibility with SonarQube <5.6.
      • Only the plugins that do something on scanner side (including of course the code analyzers but not only) should be downloaded not the other plugins like developer or governance, ... (flag in manifest to spot the plugins that should not be downloaded ?). Size saved (unpacked): ~12 MB -> won't be done for the time being.
      • Remove Guava from all the code analyzers (gain in size ?)
      • Shade dependencies in all plugins and remove unused classes.
      • Zip all plugins to be downloaded with pack200 and unzip them once before the first analysis. The CPU overhead is paid only once when creating the local cache of plugins (Note: download is also paid only once). Example of SonarJava 4.15: 6.5MB -> 1.4MB, while time to decompress in a high-end machine is 0.7s. All clients would have to implement it (SonarLint included).


      On scanner side, when downloading the plugins from the server, all the plugins are listed which can be confusing for the user since she might use a single language in her project. We should provide this level of detail only in DEBUG logs, and rather show a progress bar in default logs.

      Know limitations

      • No lazy loading of code analyzers to not download a code analyzer which is not going to be used. It's tricky because this is the responsibility of the code analyzers themselves to decide which source files they want to analyze.


      Plugin Ticket Size before (MB) Size after (MB) Size after w/ pack200 (MB)
      Python SONARPY-232 SONARPY-232 minimize 3.8 1.6 0.4
      CSharp #998 minimize and optimize protobuf stubs 3.3 1.4 0.9
      VbNet SONARVB-259 Shade minimize instead of jarjar 3.6 1.5 0.8
      XML SONARXML-63 Minimize jar and drop guava 7.4 1.4 0.7
      PLSql SONARPLSQL-647 Shade minimize instead of jarjar 2.7 1.9 0.6
      Typescript #343 Drop guava 2.4 1.6 1.2
      ABAP SONARABAP-342 Minimize jar and drop guava 2.6 0.9 0.2
      Swift SONARSWIFT-344 Minimize jar 3 2.2 0.6
      SCM Git SONARSCGIT-22 Minimize jar 3.7 2.6 0.7
      SCM SVN SONARSCSVN-16 shade jar 6.4 6.9 2.4


          Issue Links



              christophe.levis Christophe Levis
              freddy.mallet Freddy Mallet (Inactive)
              0 Vote for this issue
              1 Start watching this issue