SonarScanner seems to ignore sonar.showProfiling option

SonarQube Server / Community Build
,
1

Which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)?

SonarQube 8.1, SonarQube Scanner 4.2.0.1873, Java 11.0.3 AdoptOpenJDK (64-bit), Mac OS X 10.15.2 x86_64

What are you trying to achieve?

I’ve been investigating why scanning of one of our projects with ~3000 TypeScript files takes around 20 mins. I have hoped that enabling sonar.showProfiling option gives me some insights into where the scanner spends time. The documentation states the following about the option:

This parameter generates a file containing these timing infos in <workingDir>/profiling/<moduleKey>-profiler.xml where <workingDir> is: .sonar/profiling/ when analysis is run with SonarScanner.

Unfortunately I can’t find any profiling reports the scanner is supposed to create. There is .sonar folder in my home folder which has cache & temp files/folders but no profiling. Working folder .scannerwork doesn’t have it either. I’ve looked through a log the scanner produces with sonar.verbose=true and haven’t found any traces the scanner’s tried to generate a profiling file or failed to do so.

What have you tried so far to achieve this?

I’ve tried to set sonar.showProfiling=true in sonar-project.properties file as well as via command line argument with the same negative result.

What do I do wrong?

3

Hi,

I can’t help you with profiling, but may be I can help with the root problem, slow TS analysis.
One thing you can try is to set sonar.javascript.node.maxspace property to increase the size of memory used by Node project (set it to 4096 or 8192).

6

Hi @Lena,
thank you for your reply. I’ve tried to do what you’ve proposed and unfortunately changing that property doesn’t make any noticeable difference. I’ve run the scanner with default (no option set), 4096 and 8192 values, 3 times for each value and the difference is ~ 2% between them. I use node.js v12.13.

From the debugging information I can see the scanner starts eslint-bridge server. We use ESLint for linting typescript files in the project and it takes about 2 minutes to validate all TS files (~ 5k modules, including unit test modules which sonar scanner doesn’t check in our case). Compare it to 15 mins the scanner spends to validate 3k TS modules with comparable number of rules (I’ve disabled duplication detection to see how it affects the performance). The debugging info shows the scanner pace is 3-4 modules a second.

What I also noticed is the scanner logs the following warning:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by net.sf.cglib.core.ReflectUtils$1 (file:/<sensitive part removed>/.sonar/cache/a2b6a8802525720c8af2ca4fa85a2513/sonar-javascript-plugin.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of net.sf.cglib.core.ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Can this reflection issue negatively affect the performance?

7

No, you can ignore it.

When you use ESLint to lint TypeScript which parser do you use?

8 
parser: '@typescript-eslint/parser',
parserOptions: {
  ecmaFeatures: {
    jsx: true,
    modules: true,
  },
  ecmaVersion: 2018,
  project: './tsconfig.json',
  sourceType: 'module',
}