Использование промежуточных переменных внутри карты Spark - PullRequest
Новая
       29

Использование промежуточных переменных внутри карты Spark

0 голосов
/ 25 февраля 2019

Приводит ли создание промежуточных переменных внутри map или flatMap в Spark к снижению производительности?

Вот две версии некоторого кода, которые должны делать то же самое.

v1: 

val x = someRDD.flatMap { case(id, row) => 
    if (row.flag.isDefined)
        Some((id, (Some(row.a.get), Some(row.b.get),
              if (someFunction(row.c.get) 1 else 0, 1)))
    else
        Some((id, (Some(row.a.get), None,
              if (someFunction(row.c.get) 1 else 0, 1)))
}

v2: 

val x = someRdd.flatMap { case(id, row) =>
    val a = Some(row.a.get)
    val b = if (row.flag.isDefined) Some(row.b.get) else None
    val c = if (someFunction(row.c.get) 1 else 0
    Some((id, (a, b, c, 1)))
}

Разница в том, что v1 избегает создания промежуточных переменных, как v2.

У v2 производительность хуже по сравнениюдо v1?Требует ли создание значений a, b, c более позднего шага сборки мусора (например, из-за необходимости очистки корневых объектов ), что делает его намного медленнее?

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

Я чувствую, что с точки зрения читабельности кода v2 намного лучше, но если мы отложим v1, будет ли это преждевременной оптимизацией?

1 Ответ

0 голосов
/ 26 февраля 2019

Вероятно, для примитивных значений вообще не будет никакой разницы (например, ваша переменная c).Компилятор достаточно умен, чтобы оптимизировать его.Для ссылочных типов создание значения формально приводит к большему количеству мусора, поэтому теоретически да, это может повлиять на производительность.Однако на практике, скорее всего, вы не сможете заметить разницу в производительности (если вы не создадите много временных объектов, например, сотни и тысячи больших массивов) - есть JIT-оптимизации, которые могут выкинутьздесь, а также сборка мусора довольно эффективна в наши дни, особенно при обработке большого количества недолговечных объектов.

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

...