Как я могу ускорить анализ дизайна упаковки Sonar?

Question

Я поддерживаю процесс сборки для большого (> 500 000 LOC) Java-проекта.Я только что добавил шаг анализа сонара в конце ночных сборок.Но выполнение занимает более трех часов ... Это не серьезная проблема (это происходит в одночасье), но я хотел бы знать, могу ли я ускорить его (чтобы при желании я мог запустить его вручную в рабочее время)).

Какие-либо варианты сонара, Hudson, Maven или JDK, которые я могу настроить, могут улучшить ситуацию?

[INFO]  -------------  Analyzing Monolith
[INFO]  Selected quality profile : Sonar way, language=java
[INFO]  Configure maven plugins...
[INFO]  Sensor SquidSensor...
[INFO]  Java AST scan...
[INFO]  Java AST scan done: 103189 ms
[INFO]  Java bytecode scan...
... (snip)
[INFO]  Java bytecode scan done: 19159 ms
[INFO]  Squid extraction...
[INFO]  Package design analysis...
... (over three hour wait here)
[INFO]  Package design analysis done: 12000771 ms
[INFO]  Squid extraction done: 12277075 ms
[INFO]  Sensor SquidSensor done: 12404793 ms

12 миллионов миллисекунд = 200 минут.Это долго!Для сравнения: этапы компиляции и тестирования перед шагом сонара занимают не более 10 минут.Из того, что я могу сказать, процесс связан с процессором;большая куча не имеет никакого эффекта.Может быть, так должно быть из-за анализа путаницы / дублирования, я не знаю.Конечно, я знаю, что разделение проекта - лучший вариант!Но это займет немалое количество работы;если бы я смог настроить какую-то конфигурацию, это было бы неплохо.

Есть идеи?

Answer 1

Я ходил по вашим стопам: в проекте «2 миллиона+» (который должен был быть разбит на подпроекты много лет назад, действительно), я никогда не видел, чтобы анализ конструкции пакета завершился в течение 4 дней после вычисления ...

Начиная с SONAR-2164 (добавьте опцию, чтобы пропустить квадратичную фазу «Анализ разработки пакета») , я представил исправление, которое позволит пользователям устанавливать значение true в файле проекта maven, чтобыанализ конструкции упаковки пропущен.Этот патч ожидает одобрения и в настоящее время запланирован для включения в v2.7.

Answer 2

От Фредди Маллета в списке:

"... проблема не в БД, а в алгоритме для определения всех зависимостей пакета, которые нужно сократить. ... Если вам удастсяразделите этот проект на несколько модулей, и ваша проблема исчезнет. "

Я проверил эту теорию, исключив относительно большой пакет, и, конечно, он резко упал.Теоретически количество соединений может расти квадратично с количеством пакетов, поэтому этот подход, вероятно, настолько хорош, насколько это возможно при такой большой кодовой базе.