ALM used (GitHub, Bitbucket Cloud, Azure DevOps)
GitHub
CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI
CircleCI
Scanner command used when applicable (private details masked)
> time ../sonar/build-wrapper-macosx-x86/build-wrapper-macosx-x86 --out-dir fastlane/artifacts/sonar env NSUnbufferedIO=YES xcodebuild -scheme Scheme -project Project.xcodeproj -configuration Release COMPILER_INDEX_STORE_ENABLE=NO ONLY_ACTIVE_ARCH=YES -destination 'platform=iOS Simulator,name=iPhone 6s' clean build
real 5m19.880s
user 11m47.208s
sys 4m30.720s
> time env NSUnbufferedIO=YES xcodebuild -scheme Scheme -project Project.xcodeproj -configuration Release COMPILER_INDEX_STORE_ENABLE=NO ONLY_ACTIVE_ARCH=YES -destination 'platform=iOS Simulator,name=iPhone 6s' clean build
real 3m8.394s
user 0m4.529s
sys 0m1.693s
Languages of the repository
Obj-C, C++, Obj-C++
Hi, as you can see above, our build times increase by %50 when we use build-wrapper. What could be the reason for this?
Can I ask a simple question? Why Sonarqube can not utilize a more standard compilation information such as json-compilation-database format? Does it perform some additional analysis by intercepting the build process and checking the stack trace for example?
In the end, this %70 increase is not affordable. It would be great if you could help me detect what’s the issue.
I recognized this when I was trying to optimize build time for our lint job, and see that compile time differs too much compared to my local machine which has almost the same hw specs.
After seeing the difference, I tried a CI build with ssh access, and ran above two commands when CPUs are empty. It always repeats the case.
Do you think having too many preprocessor macros would affect the performance? for each compile command, we have a few hundreds of -D_symbol=PREFIX_symbol kind of macro definitions provided. I’m not sure if it would affect build-wrapper's performance.