Efficacité de collection.stream (). Skip (). FindFirst ()

Supposons que set est un HashSet avec n éléments et que k est un int compris entre 0 (inclus) et n (exclusif).

Quelqu’un peut-il expliquer, en termes simples, ce qui se passe réellement lorsque vous faites cela?

 set.stream().skip(k).findFirst();

En particulier, quelle est la complexité temporelle de cela? L’ajout de spliterator() à l’interface Collection signifie-t-il que nous avons maintenant un access plus rapide aux éléments “aléatoires” des collections que ce n’aurait été possible avec Java 7?

L’implémentation actuelle a une complexité de O (k) et un équivalent sans défaut des éléments suivants:

 Iterator it = set.iterator(); for(int i=0; i

L'implémentation actuelle ne prend jamais en compte la caractéristique ORDERED pour les stream séquentiels. L'élément de code cité dans la réponse @ the8472 fonctionne uniquement pour les stream parallèles. En parallèle, la complexité amortie est approximativement égale à O (k / n), n étant le nombre de processeurs.

Comme louis mentionne skip n’a pas vraiment de sens sur les stream non ordonnés, en fait, il est actuellement (jdk 1.8) mis en œuvre de manière à ce que la méthode suivante optimise le saut dans certaines circonstances:

  Spliterator unorderedSkipLimitSpliterator(Spliterator s, long skip, long limit, long sizeIfKnown) { if (skip <= sizeIfKnown) { // Use just the limit if the number of elements // to skip is <= the known pipeline size limit = limit >= 0 ? Math.min(limit, sizeIfKnown - skip) : sizeIfKnown - skip; skip = 0; } return new StreamSpliterators.UnorderedSliceSpliterator.OfRef<>(s, skip, limit); }

Ceci est valide car cela équivaut à parcourir simplement la collection source dans un ordre différent.