Комментарии 25
В общем, такая конфигурация дает большую вероятность того, что установка пройдет мгновенно т.к. медленные ПЗУ с контроллером 3.0 ставят редко. На руках Nokia 6.1. Время билда до полного запуска (проекта, который в статье) около 3х секунд.
Ну ещё можно посоветовать для JVM опцию включить -XX:+UseG1GC.
К сожалению, только с этим параметром студия не запускается. Но сразу нагуглил решение в виде
-XX:-UseParallelGC
-XX:-UseConcMarkSweepGC
-XX:+UseG1GC
Так же добавил только этот параметр в jvmargs gradle.
Не могу сказать, что увидел прирост- ребилд в пределах погрешности, в краткосрочных операциях тоже изменений не увидел. Может получится увидеть разницу в долгосрочной перспективе
Они должны влиять на производительность записи на диск, но на сколько сильно, я не проверял.
Включать опции можно только если у ПК есть ИБП (батарея).
Но в надежности есть сомнения. Я бы поостерегся в такой конфигурации работать даже с ИБП. Потеря данных дороже обойдется.
Софт:
- Android studio 3.6.3 stable, в vmoptions добавлено -Xmx4096m
- Dataram RAMDisk 4.4.0.36, опция про background update при создании диска ставилась(как бы день с git checkout начинать не стоит все же), диск создавался на системном M.2 SSD (потому что программа не умеет по другому либо этот диск надо монтировать руками каждый раз).
- SoftPerfect RAMDisk 4.1.0,'Hard drive emulation' при создании диска — выключен, галочка сохранять содержимое стоит, и отдельно стоит галочка сохранять содержимое каждые 60 мин, настройки про NUMA-ноду не включены
Все диски в NTFS
Системный M.2 SATA SSD Samsung 860 EVO M.2 250 Gb
'Второй' SATA SSD Smartbuy 480Gb
Возможности в NVMe — нет
Диск во всех случая — в NTFS.
Каталог проекта после сборки где то 3.5 Gb (сразу после checkout/после clean — 1.3 Gb)
org.gradle.caching=true,
android.enableBuildCache=true,
kapt.incremental.apt=true,
org.gradle.parallel=true,
kapt.incremental.apt=true
20+ модулей
Менять что-то в файлах проекта если нет возможности обосновать текущей задачей — придется объяснять на code review.
Проект в процессе сборки пытатся качать например material-null и так далее (видимо ошибка в конфигах)
Все каталоги в исключениях Windows Defender, 64 Gb RAM, Win 10, Ryzen 5 1600 6 core
В фоне до кучи всего висит. Включая хром с парой сотен вкладок.
В примерах где RAMDisk 6 Gb — там одновременно запущены и DataRam и SoftPerfect и их диски смонтированы. В примерах с 24 Gb RAMDisk — только SoftPerfect загружен.
Запускалось сборка несколько раз и средняя бралась в уме
- Исключения в Windows Defender НЕ прописаны. .gradle на системном M.2 SATA SSD + проект (где то 3.5 Gb со всеми сборочными каталогами) + Android SDK + AndroidSDK Home на втором SATA SSD — full rebuild примерно 8 минут
- .gradle на системном M.2 SATA SSD, проект на Dataram RAMDisk (диск 6 Gb), Android SDK + AndroidSDK Home на втором SSD. сжатие для RAM Disk НЕ включено. full rebuild примерно 4 минуты
- .gradle на системном M.2 SATA SSD проект на SoftPerfect RAMDisk(диск 6 Gb, '),Android SDK + AndroidSDK Home на втором SSD. Cжатие для RAM Disk НЕ включено. full rebuild примерно 4 минуты (хотя по CrystalDiskMark он быстрее в 3 раза чем Dataram)
- SoftPerfect RAMDisk(24 Gb, настройки те же), .gradle и проект на RAM Disk, ,Android SDK + AndroidSDK Home на втором SSD. Сжатие для RAM Disk НЕ включено. Full rebuild примерно 2 минуты 30 секунд
- SoftPerfect RAMDisk(24 Gb), .gradle и проект на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD. Включено сжатие NTFS для RAMDisk. Full rebuild — нет существенно разницы с предыдущим пунктом.
- SoftPerfect RAMDisk(24 Gb), .gradle и проект на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD. Включено сжатие NTFS для RAMDisk. Чекбокс Offline work — стоит. Full rebuild 1 минута 30 секунд
- SoftPerfect RAMDisk(24 Gb), .gradle на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD, проект тоже на на нем же (ну — для проверки), включено сжатие NTFS и все файлы на RAMDisk — сжаты (на SSD — нет). чекбокс Offline work. Full rebuild — скачет — 3 — 4 минуты 4 минуты 10 секунд
Android Studio 4.0
Проект немного эволюционировал.
PrimoCache 3.2.0 подцеплен
- .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. Rebuild — 3m 30s — 4m 30s
- Подключен PrimoCache 3.2.0 (22 Gb L1 кэш, L2 нет) 16 Kb block, включен defer-writes с latency 10 секунд, все равно бесперебойник есть и бекап тоже есть раз в сутки), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. Rebuild — 3m 20s — 3m 30s — и смысл?, ну кроме того что время пересборки не скачет, кэш по статистике в GUI PrimoCache используется где то процентов на 30. Изменение block size не особо меняет результат.
- Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. rebuild 3m 30s — особого смысла поднимат latency — нету
- Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд, .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work стоит. rebuild 3m 30s — в gradle offline в данном случае тоже мало смысла
- Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. rebuild 3m 30s — особого смысла поднимать latency — нету
Особо роста эффективности full rebuild от PrimoCache нет (обычные debug запуски, пуск эмуляторов — чуть побыстрее). И от памяти выделенной — не зависит.
Замечание — это именно в плане сборки, для некоторых других, не имеющих отношения к разработке, задач, PrimoCache помогает неслабо (хотя бы тем что, что там данных под сотню гигабайт, активная работа со считанными гигабайтами обычно но вот только — обычно).
Замечание 2 — 22 Gb кеша для PrimoCache — избыточно (он все равно в лучшем случае чуть больше половины использует)
Замечание 3 — L2 кэш запросто может замедлить (для тестов получилось только внешний USB3 SSD найти на 256 Gb — получалось незначительное замедление) — ну L2 кеш это для HDD видимо а на этой машине HDD это только диск для бекапов.
Интересно, Intel Optane, в PCIe 3.0 x1 (потому что у меня нет других свободных слотов, только пара x1, x16 занят видеокартой) — поможет (если туда содержимое 'второго SSD' скопировать)?
Новые эксперименты:
— без ramdisk'ов/PrimoCache, но в %HOME%/.gradle/gradle.properties добавлено
org.gradle.jvmargs=-Xmx4096M -Dkotlin.daemon.jvm.options\="-Xmx10240M" — XX\:MaxPermSize\=10240m + принудительно включен gradle daemon
(в самом проекте gradle.options использует значительно меньшие лимиты и демон отключен — есть причины) — full rebuilld от 8 до 20 минут. а вот make project/run debug — 1-4 минуты.
Ну и для интереса (использовать это я пока не могу — эмулятор ж не запустить из WSL, а для запуска на устройстве надо решить кое какие проектоспецифичные проблемы)
Android Studio 4.0.1 for Linux, WSL2, дефолтное ядро WSL2, Ubuntu 18.04 из MS Store(обновленная), X Server — X410 (тоже из MS Store), в оконном режиме.
— проект на ФС WSL (а не монтированной через /mnt/ ФС хоста), без правки gradle.properties:
full rebuild 16m, make project 19s
— проект на ФС WSL (а не монтированной через /mnt/ ФС хоста). c правкой gradle.properties как выше: нет существенных отличий
— проект на /mnt/ (ФС хоста монтированная) — gradle sync проекта идет более 6 минут (который во всех остальных случаях шел менее минуты). не вижу смысла дальше что-то мерять
Дополнение очередное.
Проект в стадии активного выкидывания всего в модули, очередного редизайна.
Android Studio 4.1.2 теперь как основная.
Замеры (указаны более менее средние числа)
- Mac Mini 2020 (Apple Silicon)/16 Gb RAM + Android Studio 4.1.2: full rebuild 13m, после правок в app 3m
- Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Apple Silicon / Project JDK:Azul 15 for Apple Silicon: full rebuild: 12m, после правок в app 1m 20s
- Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Intel / Project JDK:Azul 15 for Intel: full rebuild: 16m, после правок в app 2m 20s
- Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Apple Silicon / Project JDK: встроенный: сборка работает странно. очень. Ну правда это EAP. Full rebuild:14m если соберется, после правок в app — 40s-1m 30s
- та же Win10 машинка что и раньше (проект на дополнительном SSD, SDK и прочее — на системном), все SATA(в NVMe эта машинка не умеет)/Android Studio 4.1.2 / Project JDK: встроенный: full rebuild 18m, после правок в app 3m
- Mac Mini Late 2012. 16 Gb RAM (Больше не лезет), Samsung 860 EVO 1 Tb (lifetime left где то 50%, Android Studio 4.1.2 / Project JDK: встроенный: full rebuild:26m, после правок в app — 1m 40s
Возможные недостатки теста:
- не проверялась та же сборка IDEA на остальных машинах. Но вообщем то
- все SSD в тестах кроме как на новом Mac Mini — SATA. Нет возможности проверить на машинках с NVMe.
Замечания
- Android Emulator на Apple Silicon не было даже желания проверять. WiFi debugging на реальных устройствах.
- Кэш gradle — чистился.
- у других разработчиков проекта — цифры примерного того же порядка.
- в том файле viewmodel что правился в app — куча даггровских инжектов в контструктор и он сам по себе 'мелкий'. Всего то ~1800 строк.
Модификации для сборки в IDEA на Apple Silicon / вообще
Пришлось править (возможно это повлияло на результаты), модификации делятся на 2 группы:
правки самого кода проекта (там есть странности которые мешают собирать в IDEA, быстрее было повырубать например некоторые тесты)
адаптация под Apple Silicon:
Room:
перед kapt "androidx.room:room-compiler:${versions.room}"
во всех gradle файлах добавлено
//Temp fix for M1 per https://issuetracker.google.com/issues/174695268 kapt("org.xerial:sqlite-jdbc:3.34.0")
иначе вылетает No native library is found for os.name=Mac and os.arch=aarch64. path=/org/sqlite/native/Mac/aarch64
Protobuf:
в https://github.com/protocolbuffers/protobuf/issues/8062 сказано что сборки будут через некоторое время (а у нас еще и не последняя версия).
качаю нужные для Intel бинарники (система скажет какие) и /usr/loca/bin а затем правлю .gradle-файл (собрать рукам быстро — не получилось, с Ruby на Apple Silicon какие то отдельные заморочки если без Rosetta 2, а в сборке Protobuf он используется) примерно по мотивам
protobuf { protoc { //M1 fix, надо локально собранный/скачаный protoc 3.0.0 который запустится на машине //это может быть обычный x86-64-protoc path = '/usr/local/bin/protoc' //artifact = 'com.google.protobuf:protoc:3.0.0' } plugins { javalite { //M1 fix, надо локально собранный/скачаный protoc 3.0.0 который запустится на машине //это может быть обычный x86-64-protoc path = '/usr/local/bin/protoc-gen-javalite' //artifact = 'com.google.protobuf:protoc-gen-javalite:3.0.0' } }
решение конечно только для тестов. для вливания в dev — тут надо как то по другому решить вопрос.
Выводы
- возможная ошибка при импорте проекта в IDEA (похоже что-то лишнее собирается)
- Mac Mini / Apple Silicon рулит (еще бы стоил подешевле). Но очень возможно что например win-машинка с быстрыми NVMe была бы лучше. И вероятно — дешевле (тем более что видеокарта бы точно переехала в новую, а в старую встала бы заглушка 1050)
- Rosetta 2 работает очень очень хорошо в данном случае.
- особого смысла даже на Apple Silicon вот так срочно на IDEA CE Beta for Apple Silicon видимо нет, с учетом необходимых правок.
По поводу мини на m1 — при том же энергопотреблении и тепловыделении на x86, наверно, ничего собрать не получится. Однако, если не учитывать этот параметр, правильно подобранная машина на NVME будет быстрее за те же деньги.
Мини хорош для небольших и средних проектов. Единственный минус, который вижу — максимальный объем RAM в 16GB. Для крупных долгостроев этого уже будет мало.
IDEA у меня был выставлен объем 2048 Mb.
AS везде в 1920 Mb
Жалоб не было от IDE.
Открывается только не очень быстро.
У мака еще преимущество в том что "правильно подбирать" не надо и рисков ошибиться поменьше.
Вот только даже эту машину с 16 Gb не так просто было купить (диск там тоже не 256 Gb). Это хорошо что ситилинк берет заказы вообщем то на любые конфиги и доставляет в разумные сроки.
А энергопотребление меня волнует только в том плане что на mac mini с m1 новом сейчас (браузер и прочее, по сути в покое) температура('общий' индикатор iStat Menus) 34 градуса. При сборке проекта — 50 градусов.
на старом (Late 2012) — 65-70 градуса (опять же по сути в покое) (ладно, возможно мой цвет волос -:) повлиял при монтаже SSD и было нарушено обтекание воздуха). Кулер при этом уже не родной (старый тупо сдох) и работает он на 4500-5500 оборотов. и 99 градусов и 5500 оборотов при сборке проекта.
Mac Mini 2020 (Apple Silicon)/16 Gb RAM + Android Studio 4.1.2
Проект перенесен на подключенный по USB Samsung T5 SSD 1 Tb (он USB3 с внутренним SATA ), gradle cache и Android Studio — на прежнем месте — full rebuild — 15m (одна из причин зачем это может быть надо — у как минимум некоторых macmini m1, включая мой, ресурс SSD расходуется достаточно активно, а он там — не заменяемый).
С Samsung X5 (который TB3 с внутренним NVMe) пока нет возможности потестить.
Продолжение тестов.
Упомянутый проект с тех пор немного подрос, очень много чего вынесено в модули но главный модуль по прежнему жив. Все 'простые' оптимизации что можно в gradle.properties сделать — уже сделаны конечно.
Та же машина ( https://habr.com/ru/post/433604/#comment_21652966) 64 Gb RAM, Ryzen 5 1600 6 core / системный M.2 SATA SSD Samsung 860 EVO M.2 250 Gb / 'Второй' SATA SSD
Smartbuy 480Gb (проект тут) / рабочие каталоги исключены из Windows Defender,etc, только уже не Win10 а Win11
PrimoCache и прочие DATARAM'ы не используются.
Android Studio Bumblebee RC1 (Arctic Fox дико лагает в некоторых случаях при редактировании)
Время холодной сборки минут 35-40. Горячая — минут 10.
(для ускорения некоторого — был сделан настраиваемый минимальный вариант главного модуля, те кому надо его копируют и правят по себя, с ним холодная сборка от 3 до 10 минут (смотря как настроено) но вот горячая сборка — менее 2 минут).
Новая машина с 128 Gb RAM, 2xXeon E5-2680 v4(2x14 core), NVMe SSD под систему и проект.
Холодная сборка — 9-10 минут.
Судя по некоторым другим тестам — от NVMe эффекта больше чем от кучи ядер, видимо потому что у холодной сборки critical path все равно примерно 6 минут (главный модуль надо бы дальше пилить) а в single-core эти Xeon'ы даже немного хуже Ryzen'а.
Матплата для Xeon, наверное, что-то вроде JINGSHA X99 Lga 2011-V3 ?
Есть определенные подозрения что в статье https://habr.com/ru/post/700744/ описывается этот же проект но на текущий момент.
Комфортная работа с Android Studio