estimationSize () sur Spliterator séquentiel

L’examen de la hiérarchie des appels par rapport à la caractéristique de séparateur pertinente révèle qu’il est au moins pertinent pour les stream.toArray() de stream.toArray()

De plus, il existe un indicateur équivalent dans l’implémentation de stream interne qui semble être utilisé pour le sorting:

Donc, mis à part les opérations en parallèle, l’estimation de la taille semble être utilisée pour ces deux opérations.

Je ne prétends pas être exhaustif dans ma recherche, alors prenez-les comme exemples.

Sans la caractéristique SIZED, je ne peux trouver que les appels à estimateSize() qui sont pertinents pour l’exécution parallèle du pipeline de stream.

Bien sûr, cela pourrait changer dans le futur ou une autre implémentation de Stream que celle proposée par le JDK standard pourrait agir différemment.

Un séparateur peut traverser des éléments:

1.Individuellement ( tryAdvance () )

2.Sensiblement en vrac ( forEachRemaining () )

Selon java docs, estimateSize() est pratique lors du fractionnement.

Les séparateurs peuvent fournir une estimation du nombre d’éléments restants via la méthode estimationSize (). Idéalement, comme indiqué dans la caractéristique SIZED, cette valeur correspond exactement au nombre d’éléments rencontrés lors d’une traversée réussie. Cependant, même si elles ne sont pas exactement connues, une valeur estimée peut toujours être utile pour les opérations effectuées sur la source, notamment pour déterminer s’il est préférable de scinder davantage ou de parcourir les éléments restants de manière séquentielle .

Puisque votre séparateur n’a pas la caractéristique SIZED estimateSize n’offrira aucune performance (en raison de l’absence de parallélisme), gardez toutefois à l’esprit que les documents Java de estimateSize ne mentionnent rien du parallélisme, tout ce qu’il dit est:

Retourne: la taille estimée, ou Long.MAX_VALUE si infini, inconnu ou trop coûteux à calculer.