アイテムのリストを並列処理するときに、Futures(並列コレクションと比較して)の複雑さが増すのには十分な理由がありますか?
List(...).par.foreach(x=>longRunningAction(x))
vs
Future.traverse(List(...)) (x=>Future(longRunningAction(x)))
アイテムのリストを並列処理するときに、Futures(並列コレクションと比較して)の複雑さが増すのには十分な理由がありますか?
List(...).par.foreach(x=>longRunningAction(x))
vs
Future.traverse(List(...)) (x=>Future(longRunningAction(x)))
主な利点は、計算が完了するとすぐに各未来の結果にアクセスできることですが、並列コレクションで計算全体が完了するのを待つ必要があることです。不利な点は、多くの先物を作成してしまうことかもしれません。後でFuture.sequenceを呼び出すことになった場合、実際には利点はありません。
並列コレクションは、すべてのアイテムの処理に近づくにつれて、一部のスレッドを強制終了します。したがって、最後のいくつかのアイテムはシングルスレッドで処理される可能性があります。この動作の詳細については、私の質問を参照してください。Scalaでの並列コレクションのタスクサポートとしてThreadPoolTaskSupportを使用する
Futureはそのようなことをせず、すべてのオブジェクトが処理されるまで、すべてのスレッドが使用されます。したがって、タスクが小さすぎて最後のいくつかのタスクの並列処理が失われることを気にせず、できるだけ早く強制終了する必要のある膨大な数のスレッドを使用している場合を除いて、Futuresの方が優れています。
先物は、据え置き/並行計算を作成したいときにすぐに役立ちます。Futures(とにかく、Akkaのような良い種類)は単調であるため、Futuresライブラリによってすべての同時実行性と同期性が適切に処理された任意の複雑な計算構造を構築できます。