Убедитесь, что разветвленные элементы принадлежат одному разветвленному элементу. - PullRequest
Новая
       11

Убедитесь, что разветвленные элементы принадлежат одному разветвленному элементу.

0 голосов
/ 30 апреля 2019

Допустим, у нас есть график, который выглядит следующим образом: 

          broadcast ~> flowA ~> fanIn
source ~> broadcast ~> flowB ~> fanIn ~> sink
          broadcast ~> flowC ~> fanIn

Потоки flowA, flowB, flowC все выполняют преобразование для входящих элементов.fanIn выполняет некоторое объединяющее действие с результатами всех трех потоков.

Проблема заключается в том, что потоки A / B / C не излучают элементы с одинаковой скоростью.Для некоторых элементов источника flowA нечего излучать, в то время как flowB и C продолжают излучать.

Теперь, на fanIn Я хочу быть уверен, что полученные элементы на всех трехпорты «принадлежат» одному и тому же элементу, исходящему из источника, то есть они являются результатом преобразований одного и того же элемента.

Как можно это сделать?

Мое текущее решение состоит в том, чтобыимеют потоки A / B / C испускают Option с.Каждый поток генерирует Some, если он может выполнить преобразование, и None, если он не может.Таким образом, количество испускаемых элементов и скорость во всех трех потоках остаются неизменными, и я могу гарантировать, что полученные элементы принадлежат одному и тому же элементу источника.Я ищу более эффективное решение, которое, по возможности, не требует ненужного создания и переноса объектов.

1 Ответ

2 голосов
/ 02 мая 2019

Возвращая None, не создаст новый объект ... Обтекание для Some (не для Option, который будет выполнять проверку нуля) также может повысить производительность. Я думаю, что вы действительно не можете обойтись без нулевого элемента, но если у вас есть nonValid / null в вашем типе возврата, который также можно использовать как None. (Например, если это объекты с длинным идентификатором, вы можете создать недопустимый элемент с элементом id = -1 и отфильтровать его.) Я думаю, здесь не будет серебряной пули.

НО: я думаю, что это не проблема, вы не потеряете значительную производительность, ваш код, вероятно, будет иметь гораздо более узкие места, так что отпустите: D

(передал мой ответ из обсуждения lightbend )

...