Hey again @user_user @morco @justoaguilar @Cyril035
While I haven’t been able to reproduce your exact performance degradation, I did some investigation.
I decided to take a big project (~4000 files, 850k LoC, just a modified version of what’s in GitHub - SonarSource/sonar-scanning-examples: Shows how to use the Scanners), run my own tests, and measure the time for:
- First analysis of the main branch
- Second analysis of the main branch
- First analysis of a non-main branch (after the first two analyses)
This was all done on brand new SQ servers (no upgrading) against a local Postgres server. Admittedly, a fairly optimal setup.
I chose these versions to compare the last LTA, to 10.3 (where we did a lot of refactoring of the DB model), to 10.4 (new measures as noted in SONAR-21949), and 10.7 (the latest)
These are the results:
| Version | 1st Scan | 2nd Scan | 1st Scan New Non-Main Branch |
|---|---|---|---|
| 9.9.7 | 48s | 39s | 28s |
| 10.3 | 49s | 35s | 70s |
| 10.4 | 67s | 50s | 66s |
| 10.7 | 58s | 56s | 97s |
It definitely looks like something we should investigate, and I’ve passed this on to the right folks.
I would be curious to know if your performance issues also start only at 10.3/10.4 (@morco made clear this is the case), but I understand that it’s quite some work to reproduce.
I’ll keep you posted if something comes out of it, on top of the performance improvements we already expect in 10.8 with SONAR-22870.