問題タブ [spliterator]

returnSpliteratorを持つことで並列化を明示的に制限する を実装しています。実装すると、このスプリッテレータによって生成されるストリームのパフォーマンスが向上しますか? それとも、推定サイズは並列化にのみ役立ちますか?trySplit()nullestimateSize()

編集：明確にするために、私は具体的に推定サイズについて尋ねています. つまり、私のスプリッテレータにはその特性がありませんSIZED。

それはどのように機能しますか？どのConsumer<? super Integer>ようにキャストできますIntConsumerか??

私が書いているライブラリの低レベルの操作には、ストリーム スプリッテレータを直接使用しています。tryAdvance/trySplit最近、ストリーム スプリッターとインターリーブの呼び出しを行ったときに、非常に奇妙な動作を発見しました。問題を示す簡単なコードを次に示します。

出力は

ご覧のとおり、フラット マッピングの後、 から1までの連続した数字の順序付きストリームを取得する必要があり9ます。スプリッテレータを 1 回分割したので、中間の場所にジャンプする必要があります。次に、そこから要素を消費し、もう一度分割します。その後、残りの要素をすべて出力します。ストリームの末尾からいくつかの連続した要素があることを期待しています (おそらく要素はゼロですが、それも問題ありません)。しかし、私が得たのは5and6で、突然 にジャンプしました9。

現在、JDK スプリッテレータはこのように使用されていないことを知っています。それらは常にトラバーサルの前に分割されます。ただし、公式ドキュメントtrySplitでは、 afterを呼び出すことを明示的に禁止していませんtryAdvance。

コレクション、配列、生成されたソースなどから直接作成されたスプリッテレータを使用した場合、問題は発生しませんでした。スプリッテレータが中間を持つ並列ストリームから作成された場合にのみ発生しますflatMap。

問題は、私がバグに遭遇したのか、それともスプリッテレータをこのように使用することがどこかで明示的に禁止されているのかということです。

スプリッテレータも実装するデータ構造が与えられたとします。そのスプリッテレータを使用した並列処理が実際に順次処理よりも優れているかどうかをテストする定型コードは何ですか?

並列の処理を設定するとオーバーヘッドが発生することStream、アイテム数が少ない場合や各アイテムの処理が速い場合はシングルスレッドでの処理の方が早いことは理解しています。

trySplit()しかし、問題をより小さなチャンクに分解することが逆効果になる点について、同様のしきい値はありますか? 私は、マージソートが最小チャンクの挿入ソートに切り替わることに類推して考えています。

もしそうなら、閾値は相対的なコストtrySplit()とアイテムの消費tryAdvance()に依存しますか? 配列インデックスを進めるよりもはるかに複雑な分割操作を考えてみましょう。たとえば、語彙的に順序付けられた multiset 順列を分割します。コンシューマーの複雑さに応じて、クライアントが並列ストリームを作成するときに分割の下限を指定できるようにする規則はありますか? Spliterator下限自体を推定するために使用できるヒューリスティック?

あるいは、a の下限をSpliterator1 にして、ワークスティーリング アルゴリズムに分割を続行するかどうかの選択を任せることは常に安全ですか?

これは、不変のリンク リストの古典的な実装です。

のデフォルトの実装は、spliterator()効率的な並列化をサポートしていません。

1, 2, 3これで順次印刷されます。

spliterator()効率的な並列化をサポートするために実装する方法は?