returnSpliterator
を持つことで並列化を明示的に制限する を実装しています。実装すると、このスプリッテレータによって生成されるストリームのパフォーマンスが向上しますか? それとも、推定サイズは並列化にのみ役立ちますか?trySplit()
null
estimateSize()
編集:明確にするために、私は具体的に推定サイズについて尋ねています. つまり、私のスプリッテレータにはその特性がありませんSIZED
。
returnSpliterator
を持つことで並列化を明示的に制限する を実装しています。実装すると、このスプリッテレータによって生成されるストリームのパフォーマンスが向上しますか? それとも、推定サイズは並列化にのみ役立ちますか?trySplit()
null
estimateSize()
編集:明確にするために、私は具体的に推定サイズについて尋ねています. つまり、私のスプリッテレータにはその特性がありませんSIZED
。
関連するスプリッテレータの特性への呼び出し階層を見ると、少なくともstream.toArray()
パフォーマンスに関連していることがわかります
さらに、内部ストリームの実装には、ソートに使用されると思われる同等のフラグがあります。
したがって、並列ストリーム操作は別として、サイズの見積もりはこれら2つの操作に使用されるようです。
私の検索が網羅的であるとは主張していないので、例として挙げてください。
SIZED 特性がなければ、estimateSize()
ストリーム パイプラインの並列実行に関連する呼び出しのみを見つけることができます。
もちろん、これは将来変更される可能性があります。または、標準の JDK とは別の Stream 実装が異なる動作をする可能性があります。
スプリッテレータは要素を走査できます:
1.個別に( tryAdvance() )
2.順次一括( forEachRemaining() )
Java docs ごとestimateSize()
に、分割中に便利です。
スプリッテレータは、estimateSize() メソッドを介して残りの要素数の見積もりを提供できます。理想的には、特性 SIZED に反映されているように、この値は、トラバーサルが成功したときに検出される要素の数に正確に対応します。ただし、正確にわからない場合でも、推定値は、ソースで実行されている操作に役立つ場合があります。たとえば、さらに分割するか、残りの要素を順番にトラバースするかを判断するのに役立ちます。
スプリッテレータには SIZED 特性 estimateSize
がないため、パフォーマンスは提供されません (並列処理がないため) estimateSize
。
戻り値: 推定サイズ、または無限、不明、または計算コストが高すぎる場合は Long.MAX_VALUE。