https://kotlinlang.org logo
#russian
Title
# russian
a

alexey.tsvetkov

01/14/2019, 2:22 PM
@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
.
👍 2
e

Eugen Martynov

01/14/2019, 2:45 PM
спасибо!
g

gildor

01/15/2019, 5:57 AM
Т.е. возможность настроить количество памяти для kapt worker появится после 1.3.20?
a

alexey.tsvetkov

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

gildor

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

alexey.tsvetkov

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

gildor

01/31/2019, 2:35 PM
@alexey.tsvetkov Интересно, ясно. А в чем проблема изолированных воркеров в Gradle? Есть какие то потенциальные бонусы переезда на воркеров собственного демона? Сейчас демоны гредл и котлиг отъедают у нас равное количество памяти, задание для Gradle, но в двойном размере, поможет ли это память экономить и больше шарить между компилятором и Gradle?
Про kapt воркеры и проблему с их большим числом и тем что каждый отъедает много памяти мы заметили через неделю как включили kapt.workers, через время выключили стало заметно лучше
a

alexey.tsvetkov

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

gildor

02/01/2019, 1:27 AM
не использовать org.gradle.parallel в мультимодульном проекте в любом случае так себе идея