Производительность сборки для конкретной ОС в Java

В настоящее время мы оцениваем конфигурацию ПК для разработчиков нового поколения для всей компании и заметили кое-что действительно странное.

У нашего довольно большого монолита - в нашей текущей конфигурации время сборки ок. 4,5 минуты (без теста, просто скомпилируйте).

Для нашей конфигурации следующего поколения мы обновили несколько компонентов. Умеренное увеличение частоты и IPC с процессором, удвоение количества ядер ЦП и переход с небольшого твердотельного накопителя SATA на твердотельный накопитель NVMe с пропускной способностью> 3 Гбит / с. Кроме того, конфигурация следующего поколения переключается с Windows 7 на Windows 10.

При выполнении первых тестов мы заметили почти идентичное время сборки (4,3 минуты), что было намного меньшим улучшением, чем мы ожидали.

Во время наших экспериментов мы однажды попытались запустить процесс сборки из виртуальной машины Linux, работающей на хосте Windows. В старой конфигурации (Windows7) время сборки уменьшилось с 4,5 до ~ 3,7 минут, на хосте Windows 10 - с 4,3 до 2,3 минут. Мы исключили такие вещи, как проверка на вирусы.

Мы были довольно удивлены этими результатами и попытались найти другое объяснение, чем несколько почти религиозных и оскорбительных заявлений о различных операционных системах.

Возникает вопрос: что мы могли сделать не так, настроив машину Windows так, чтобы скорость была почти вдвое меньше скорости Linux, работающей виртуализированной на том же самом хосте Windows? Тем более, что все аппаратные достижения, похоже, съедены переключением с Windows 7 на 10.

Другой вопрос: как мы можем ускорить процесс javac, чтобы использовать больше ядер, потому что прямо сейчас, используя Hotspot JDK 8, мы можем видеть не более двух ядер, действительно используемых сборкой. Я читал о sjavac, но это кажется довольно экспериментальной функцией, доступной только для OpenJDK9, не так ли?


person Jonathan    schedule 17.02.2018    source источник


Ответы (1)


После почти года экспериментов мы пришли к выводу, что злоумышленником действительно является NTFS. Если у вас есть пользовательский раздел ntfs с хостом linux, вы получите несколько схожие результаты по сравнению с установкой для всех окон.

Мы провели тесты gradle-build, внутреннюю сборку eclipse, запуск wildfly и тесты, ориентированные на базу данных, на нескольких устройствах. Все наши тесты показали стабильное ускорение как минимум на 100% при переходе с Windows на Linux (иногда Windows занимает в реальных тестах в 3 раза больше времени, чем Linux, а некоторые искусственные тесты имеют ускорение на 60!). В частности, на ноутбуках мы испытали гораздо меньше шума, так как общая загрузка процессора при полной сборке значительно меньше, чем при использовании Windows.

Мы пришли к выводу, что за последний год нужно было перейти с Windows на Linux.

Что касается параллелизации, мы поняли, что это была некоторая форма запутанности кода. Решение этой проблемы помогло gradle и javac в значительной степени распараллелить сборку (также взгляните на gradle-Composite-builds)

person Jonathan    schedule 13.02.2019