# SonarQube 2026.1.5 Developer Edition: IntegrateIssuesVisitor takes ~43 minutes on a 14k file project
Hi,
I’m investigating a significant performance issue in SonarQube 2025.1 Developer Edition and have narrowed the problem down quite significantly.
## Environment
- SonarQube 2025.1 Developer Edition
- Azure VM
- Azure SQL Database
- ~14,000 files
- ~16,800 components
- Issue count is only in the low thousands (4-digit range)
## Performance Breakdown
After enabling CE DEBUG logging I found:
Execute component visitors = 2638413ms
Breakdown:
IntegrateIssuesVisitor 2611499ms
LoadComponentUuidsHavingOpenIssuesVisitor 25281ms
Everything else < 1 second
So essentially:
IntegrateIssuesVisitor = 99% of Execute component visitors
## Database Investigation
Initially I suspected SQL performance.
I found:
- Severe index fragmentation (70-99% on many SonarQube tables)
- Missing index recommendations
- Key Lookups on file_sources
- Key Lookups on measures
Actions performed:
ALTER INDEX ALL … REBUILD
EXEC sp_updatestats
After that:
- Most indexes are now below 1% fragmentation
- Execution plans look healthy
- Query runtimes did not significantly change overall analysis duration
The bottleneck remains:
IntegrateIssuesVisitor
## AI Code Detection
During the entire IntegrateIssuesVisitor phase I see:
[AICodeDetection] Abort AI Code detection …
for many files.
Initially this looked suspicious because the timestamps span almost the entire visitor runtime.
However TRACE logging shows:
Visiting component …
[AICodeDetection] Abort …
Visiting component … (done) | time=0ms
So AI code detection currently does not appear to be the primary bottleneck.
## TRACE Findings
After enabling SQL TRACE logging I noticed that IntegrateIssuesVisitor performs multiple queries for every file.
Example:
Visiting component file.cs
Query 1: project lookup
Query 2: project load
Query 3: anticipated_transitions lookup
Query 4: issues lookup
Visiting component file.cs (done) | time=151ms
Example queries:
SELECT ...
FROM projects p
WHERE p.qualifier='TRK'
AND p.kee=?
SELECT ...
FROM anticipated_transitions
WHERE project_uuid=?
AND file_path=?
SELECT ...
FROM issues i
...
WHERE i.component_uuid = ?
AND i.status <> 'CLOSED'
ORDER BY i.kee
## Surprising Observation
For the tested file, the issues query returned:
0 rows
Yet IntegrateIssuesVisitor still performs the full workflow for that file.
Additionally, the project lookup uses the same project key every time, meaning the same project information appears to be loaded repeatedly for many files.
## Query Timing Analysis
The SQL queries themselves do not appear to be inherently expensive.
For example, the issues query shown above returns 0 rows for the tested component.
When executed directly in SQL Server Management Studio, SQL Server reports an execution time of 0 ms on the server side.
When enabling SSMS Client Statistics, the measured Client Execution Time is approximately 15 ms, which is very close to the 11-19 ms timings reported by SonarQube TRACE logging.
This suggests that the observed query time is largely end-to-end execution time (including client processing, network round-trips, result handling, etc.) rather than expensive server-side execution.
The main observation is therefore not that any individual query is slow, but that the same sequence of queries appears to be executed repeatedly for every file.
## Per-file Timings
Typical TRACE timings:
11ms
18ms
11ms
19ms
Total visitor time for the file:
~151ms
This means that only a fraction of the per-file processing time is spent executing SQL statements. The remaining time is spent inside the visitor itself.
The cumulative cost becomes significant when multiplied across the entire project.
With approximately:
14,000 files
this roughly matches the observed runtime:
14,000 × 151ms ≈ 35 minutes
which is in the same order of magnitude as the measured:
IntegrateIssuesVisitor ≈ 43.5 minutes
## Questions
From the TRACE logs it appears that:
1. Project information is repeatedly loaded for individual files.
2. Issue-related queries are executed even for files with no open issues.
3. IntegrateIssuesVisitor appears to process files individually rather than starting from a preloaded set of components with open issues.
My expectation would be something closer to:
- Load project metadata once per analysis.
- Load relevant component UUIDs with open issues once.
- Process only the relevant subset of components/files.
- Reuse project-level information throughout the visitor execution.
Is this expected behavior in SonarQube 2025.1?
Has anyone seen similar performance characteristics with:
IntegrateIssuesVisitor
on large projects (10k+ files)?
Is there some rationale behind repeatedly loading project information and executing issue lookups for files that have no open issues?
Any guidance would be appreciated.
Thanks!