Comments 10
ps: выводы совершенно странные.
1. Вся сборка очень много занимается перекладыванием из пустого в порожнее. По этому главным критерием будет количество каналов памяти у процессора и скорость и объём кэша процессора. Короче попробуйте на 12 канальном Xeon.
2. HDD по вашим тестам смотрится очень достойно 10% при отличии скорости в 60раз (120мб/c HDD и 7Гб/c у SSD).
Количество каналов памяти, как я понимаю, в основном повысит пропускную способность памяти. Поднятие частоты памяти тоже на это влияет. Но по тестам частота/пропускная способность памяти почти не повлияла. Как будто увеличение количества каналов не должно помочь. Или я заблуждаюсь?
По поводу кэша - да. Чем его больше - тем лучше) Но тут сложно определить насколько именно. Наверно только если сравнить Ryzen 5800X и Ryzen 5800X3D которые только размером кэша и отличаются.Тут речь скорее про то, что замена HDD на SSD достаточно дешёвый способ увеличить скорость сборки. Относительно замены процессора или оперативной памяти, конечно же. Так что, честно говоря, не вижу особого смысла собираться на HDD.
ps: я к тому что «HDD пока!» преждевременно.
pps: и еще не смотря на все удобства gradle очень тормозной и избыточный. Время и ресурсов для сборки без gradle надо порядки меньше.
Спасибо за статью. Результаты более чем предсказуемые, но труд большой.
Вы тестировали, по сути, JVM на специфической задаче: интенсивная работа с большим количеством мелких фалов и компиляция. Понятно что для первого наибольший выигрыш дает SSD а для второго - частота ядер (и их количество если нагрузка для них есть). Threadripper лучший выбор процессора, для этой задачи, полагаю. Линус Торвальдс и Алексей Шипилёв не дадут соврать :)
И спасибо за подсказку выбрать другой GC - оно и с Maven заметно помогло (задача-то таже)
Можно заметить, что сборка с частотой, выставленной в Auto режиме, в котором частоты должны доходить до 4200 МГц, собиралась 10:32, но когда мы руками выставляли 4200 МГц, то результат был 8:46
Это стандартная проблема с динамическим управлением частоты и короткими нагрузками.
Ядро простаивает — процессор сбрасывает частоту этого ядра. Потом нагрузка появляется, процессор начинает собираться почистить частоту, это дело не такое уж и быстрое. Когда он поднял частоту, может оказаться, что этот процесс уже отработал. Или планировщик перенёс его на другое ядро )
Все инструкции по обеспечению low latency начинаются с отключение понижений чистоты и там более переходов в спящие режимы.
Достаточно и обычного SSD. Относительно него от NVMe прирост не слишком большой
Вообще немного странно сравнивать «sata ssd в целом» с «nvme ssd в целом», всё-таки в обоих семействах есть модели совершенно разного класса.
Но если сосредоточиваться на различии между интерфейсами, то время доступа примерно одинаково, особенно на чтение (тут оно вообще определяется nand памятью, а не интерфейсом).
Отличаются линейные скорости (сомневаюсь, что для этой задачи это особо актуально) и возможная глубина очереди/поведение при большой глубине очереди (это тут вообще неприменимо).
Это то, чего мне реально не хватало: с каждым новым релизом студия жрёт всё больше ресурсов, и на ноуте становится тяжко проекты собирать. Теперь же знаю, на что сделать упор, при выборе нового железа, спасибо!
За одно посмотрю в сторону сборки без Gradle, хотя во многих компаниях умение с ним работать ну прям обязательное требование.
подскажите, что за сервис использовали для генерации графиков и диаграмм?
Я генерировал основной график в Google Docs. Затем обрисовывал его в https://app.diagrams.net/ и добавлял дополнительную информацию. Остальные иллюстрации тоже там делал.
Спасибо огромное за отличную статью! Плотно занимался ускорением процесса сборки очень крупного многомодульного приложения на одном из рабочих мест (несколько сотен модулей, ~2М строк кода на Java и Kotlin), тоже делал некоторые экспериментальные замеры, но не настолько дотошно как вы. У вас проделан большой труд и получена очень полезная информация, спасибо большое!
В моём случае я отметил что с точки зрения железа, наибольший профит был от количества ядер и single-core производительности. Ну и чисто с точки зрения gradle, технически, при регулярных "горячих" сборках очень выручает экспериментальная (может быть уже нет?) настройка configuration-cache, потому что при горячей сборке configuration этап gradle сборки может занимать 30-50% времени, и чем больше в проекте модулей, тем дольше он выполняется. Однако configuration-cache требует следить за подключаемыми плагинами, т.к. если они не адаптированы к свежему апи, то кэш configuration этапа ломается и не может работать.
Наверное несколько лет назад никто и подумать не мог что андроид проекты станут такими огромными, ну и gradle, AGP и сама студия жрут всё больше ресурсов с каждым годом. Чтобы не сойти с ума от времени сборки, я в итоге для себя в частном порядке начал использовать чуток допиленный вариант Mainframer'a, работал с ноутбука, подключался к мощному настольнику.
Приятно также видеть что вы ещё и KSP успели попробовать с Yatagan'ом, прям большой респект!
Какие параметры компьютера влияют на скорость сборки Gradle проекта