<@U0B8MSP9B> Лимит для враппера не очень важен. В ...

# russian

[alexey.tsvetkov]

@Eugen Martynov
Лимит для враппера не очень важен. В 5.0 появились лимиты для воркеров, 512 Мб (раньше явного лимита не было).
С воркер процессами в любом случае есть проблемы: Gradle не использует один процесс конкурентно, поэтому при параллельной сборке Gradle может создать CPU_THREADS процессов только для капта (для 4-ядерных процессоров с HT/SMT 8 процессов даже по 512 Мб это довольно много).
В 1.3.20 режим с Worker API будет по-умолчанию запускать KAPT внутри основного процесса Gradle. К сожалению, наш DSL сейчас не позволяет настраивать количество памяти для KAPT воркер процессов, поэтому пока лучше использовать kapt.use.worker.api=false.

[Eugen Martynov]

спасибо!

[gildor]

Т.е. возможность настроить количество памяти для kapt worker появится после 1.3.20?

[alexey.tsvetkov]

@gildor можно добавить, но по-моему использовать Worker процессы в Gradle очень грустно, так как Gradle может запустить очень много процессов. Запускать KAPT внутри основного процесса кажется лучшей стратегией.
Если такая фича нужна, то создайте тикет пожалуйста
kotl.in/issue

[gildor]

@alexey.tsvetkov нет, у меня нет никаких конкретных юзкейсов кроме “сделать что бы быстрее компилировалоссь и утилизировало ресурсы”
Просто учитывая что еще и компайлер в воркерах запускается с флагом kotlin.parallel.tasks.in.project, не будет ли такой же проблемы как с Kapt?

[alexey.tsvetkov]

@gildor а он не запускается в них) Мы используем воркеры, только для связи с демоном. Было бы приятно полностью отказаться от своего демона, но в Gradle режимы изоляции Classloader и Process очень проблемные сейчас.
Новый флаг помогает только в том, что появляется параллелизм внутри одного Gradle модуля (сабпроекта). Это важно для MPP проектов, а также может быть полезно при сборке независящих сорссетов/вариантов.
Также Worker API всегда работает параллельно, даже если ord.gradle.parallel=false. Поэтому если параллельная сборка раньше не была включена, то будет улучшение.

[gildor]

@alexey.tsvetkov Интересно, ясно.
А в чем проблема изолированных воркеров в Gradle? Есть какие то потенциальные бонусы переезда на воркеров собственного демона?
Сейчас демоны гредл и котлиг отъедают у нас равное количество памяти, задание для Gradle, но в двойном размере, поможет ли это память экономить и больше шарить между компилятором и Gradle?

[gildor]

Про kapt воркеры и проблему с их большим числом и тем что каждый отъедает много памяти мы заметили через неделю как включили kapt.workers, через время выключили стало заметно лучше

[alexey.tsvetkov]

Ну, проблема с тем, что нельзя один процесс использовать для нескольких потоков. Ещё с процессами нет способа нормально писать логи. Можно выводить в stdout, но как быть с разными уровнями логов.
Воркеры нигде не переезжают в собственного демона.
Мы ещё до воркеров использовали собственного демона. Он в целом хорошо работает.
У капта есть два шага -- генерация стабов и запуск annotation processors. Со вторым шагом на некоторых проектах наблюдались проблемы, то ли память текла, то ли GC плохо собирал класслоадеры для AP. Это плохо влияло на остальные шаги компиляции. Поэтому мы решили попробовать вынести kapt в изолированные процессы, но возникли проблемы с большим числом процессов.
Не предполагалось, что переход на воркеров капта всё обязательно ускорит у всех. Но кому-то могло помочь вынесение AP из основного котлиновского демона.
В целом использование воркеров может быть полезным, но либо есть есть независимые сорссеты, либо если не использовался `--parallel`/`org.gradle.parallel`. При этом использование воркер процессов создаёт проблемы, поэтому по-умолчанию мы их не используем.

[gildor]

не использовать org.gradle.parallel в мультимодульном проекте в любом случае так себе идея