Kotlin - сопрограммы вызывают интенсивную загрузку ЦП с помощью DefaultDispatcher после перехода на Kotlin 1.3 - PullRequest
0 голосов
/ 13 ноября 2018

Я давно использую экспериментальные версии сопрограмм Kotlin с высокой степенью параллелизма, и производительность всегда была превосходной.Основная логика может быть упрощена до следующего кода:

// works fine in kotlin 1.2 with 3000+ QPS for a 40-core host
launch {
  // running in ForkJoinPool.commonPool() by default
  // non-blocking IO function
  val result = supendFunction()
  doSomething(result)
}

Однако после того, как я обновил kotlin до 1.3 и перешел на формальную версию сопрограмм, как это

// kotlin 1.3 version
GlobalScope.launch {
  // running in DefaultDispatcher
  // non-blocking IO function
  val result = supendFunction()
  doSomething(result)
}

Загрузка ЦП возрастает с 2% до 50% без каких-либо исключений или ошибок.Единственное отличие, которое я заметил, состоит в том, что сопрограммы больше не выполняются в ForkJoinPool.commonPool(), как раньше.Вместо этого они работают в DefaultDispatcher потоках, например DefaultDispatcher-worker-30.

Мои вопросы:

  1. Почему это стоит так много использования процессора с DefaultDispatcher?
  2. Почему kotlin 1.3 использует DefaultDispatcher вместо ForkJoinPool.commonPool() по умолчанию?
  3. Как сохранить поведение сопрограмм так же, как и до 1.3?

1 Ответ

0 голосов
/ 13 ноября 2018
  1. Почему ЦП стоит так дорого с DefaultDispatcher?

Это совершенно другая реализация, оптимизирующая для нескольких целей производительности, например, связь черезканал.Это подлежит будущим улучшениям.

Почему kotlin 1.3 по умолчанию использует DefaultDispatcher вместо ForkJoinPool.commonPool()?

На самом деле он все время использует диспетчер Default, но разрешениеDefault изменено.На этапе эксперимента он был равен CommonPool, но теперь он предпочитает пользовательскую реализацию.

Как сохранить поведение сопрограмм так же, как и до версии 1.3?

Установить системное свойство kotlinx.coroutines.scheduler на off.

...