Java 8 Flux: plusieurs filtres vs condition complexe

Parfois, vous souhaitez filtrer une Stream avec plus d'une condition:

myList.stream().filter(x -> x.size() > 10).filter(x -> x.isCool()) ...

ou vous pourriez faire de même avec une maladie complexe et un unique filter:

myList.stream().filter(x -> x.size() > 10 && x -> x.isCool()) ...

Ma conjecture est que la deuxième approche a de meilleures caractéristiques de performances, mais je n'ai pas savoir il.

La première approche gagne en lisibilité, mais ce qui est mieux pour la performance?

  • Écrire selon le code est plus lisible dans la situation. La différence de performances est minime (et dépend de la situation).
  • Oubliez les nano-optimisations et de l'utilisation très lisible, & code maintenable. avec des cours d'eau, on devrait toujours utiliser chaque opération séparément y compris les filtres.
InformationsquelleAutor deamon | 2014-06-05
  1. 127

    Le code qui doit être exécuté pour les deux alternatives sont si proches que vous ne pouvez pas prédire un résultat fiable. L'objet sous-jacent de la structure peut varier mais c'est pas de défi à la zone sensible de l'optimiseur. Donc, cela dépend d'autres conditions environnantes qui donnera à une exécution plus rapide, si il n'y a aucune différence.

    La combinaison de deux occurrences de filtre crée plus d'objets et, par conséquent, plus de déléguer le code, mais cela peut changer si vous utilisez la méthode des références plutôt que des expressions lambda, par exemple le remplacement des filter(x -> x.isCool()) par filter(ItemType::isCool). De cette façon, vous avez éliminé le synthétique de déléguer méthode créée pour votre expression lambda. Donc la combinaison de deux filtres à l'aide de deux méthodes références peuvent créer le même ou moins délégation de code qu'une seule filter invocation à l'aide d'une expression lambda avec &&.

    Mais, comme l'a dit, ce type de surcharge seront éliminés par le HotSpot optimiseur et est négligeable.

    En théorie, deux filtres qui pourrait être plus facile parallélisée qu'un seul filtre, mais c'est uniquement pour la plutôt de calcul intense petersberg1.

    Donc il n'y a pas de réponse simple.

    La ligne du bas est, ne pense pas à de telles différences de rendement ci-dessous l'odeur seuil de détection. Utiliser ce qui est plus lisible.

    1...et aurait besoin d'une mise en œuvre faire le traitement en parallèle des étapes suivantes, une route pas actuellement pris par le Flux standard de mise en œuvre

    • ne pas le code à la parcourir le flux résultant après chaque filtre?
    • Carlos Diaz: non, les flux ne fonctionnent pas de cette façon. Lu sur “l'évaluation différée”; les opérations intermédiaires ne font rien, ils ne font que modifier le résultat de l'exploitation du terminal.
    InformationsquelleAutor Holger
  2. 19

    Ce test montre que votre deuxième option peut effectuer beaucoup mieux. Conclusions en premier, puis le code:

    one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=4142, min=29, average=41.420000, max=82}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=13315, min=117, average=133.150000, max=153}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10320, min=82, average=103.200000, max=127}

    maintenant le code:

    enum Gender {
FEMALE,
MALE
}
static class User {
Gender gender;
int age;
public User(Gender gender, int age){
this.gender = gender;
this.age = age;
}
public Gender getGender() {
return gender;
}
public void setGender(Gender gender) {
this.gender = gender;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
static long test1(List<User> users){
long time1 = System.currentTimeMillis();
users.stream()
.filter((u) -> u.getGender() == Gender.FEMALE && u.getAge() % 2 == 0)
.allMatch(u -> true);                   //least overhead terminal function I can think of
long time2 = System.currentTimeMillis();
return time2 - time1;
}
static long test2(List<User> users){
long time1 = System.currentTimeMillis();
users.stream()
.filter(u -> u.getGender() == Gender.FEMALE)
.filter(u -> u.getAge() % 2 == 0)
.allMatch(u -> true);                   //least overhead terminal function I can think of
long time2 = System.currentTimeMillis();
return time2 - time1;
}
static long test3(List<User> users){
long time1 = System.currentTimeMillis();
users.stream()
.filter(((Predicate<User>) u -> u.getGender() == Gender.FEMALE).and(u -> u.getAge() % 2 == 0))
.allMatch(u -> true);                   //least overhead terminal function I can think of
long time2 = System.currentTimeMillis();
return time2 - time1;
}
public static void main(String... args) {
int size = 10000000;
List<User> users =
IntStream.range(0,size)
.mapToObj(i -> i % 2 == 0 ? new User(Gender.MALE, i % 100) : new User(Gender.FEMALE, i % 100))
.collect(Collectors.toCollection(()->new ArrayList<>(size)));
repeat("one filter with predicate of form u -> exp1 && exp2", users, Temp::test1, 100);
repeat("two filters with predicates of form u -> exp1", users, Temp::test2, 100);
repeat("one filter with predicate of form predOne.and(pred2)", users, Temp::test3, 100);
}
private static void repeat(String name, List<User> users, ToLongFunction<List<User>> test, int iterations) {
System.out.println(name + ", list size " + users.size() + ", averaged over " + iterations + " runs: " + IntStream.range(0, iterations)
.mapToLong(i -> test.applyAsLong(users))
.summaryStatistics());
}
    • Intéressant - quand je change l'ordre d'exécuter test2 AVANT test1 test1 tourne légèrement plus lent. C'est seulement quand test1 est exécutée en premier, qu'il semble plus rapide. Quelqu'un peut-il reproduire ce ou avez des idées?
    • Il pourrait être parce que le coût de HotSpot compilation est engagée par ce test est exécuté en premier.
    InformationsquelleAutor Hank D
  3. 3

    Un filtre complexe condition est meilleure au point de vue des performances, mais les meilleures performances affichera à l'ancienne mode de boucle avec un standard if clause est la meilleure option. La différence sur un petit tableau de 10 éléments différence peut ~ 2 fois, pour un grand tableau, la différence n'est pas grande.

    Vous pouvez prendre un coup d'oeil sur mon Projet GitHub, où j'ai fait des tests de performance sur plusieurs tableau d'options d'itération

    Pour petit tableau de 10 éléments de débit ops/s:
    Java 8 Flux: plusieurs filtres vs condition complexe
    Pour les moyennes de 10 000 éléments de débit ops/s:
    Java 8 Flux: plusieurs filtres vs condition complexe
    Pour le grand tableau 1 000 000 d'éléments de débit ops/s:
    Java 8 Flux: plusieurs filtres vs condition complexe

    REMARQUE: les tests s'exécute sur

    • 8 CPU
    • 1 GO DE RAM
    • Version de l'OS: 16.04.1 LTS (Xenial Xerus)
    • version de java: 1.8.0_121
    • jvm: -XX:+UseG1GC -serveur -Xmx1024m -Xms1024m
    InformationsquelleAutor Serge
  4. 1

    C'est le résultat de l'6 combinaisons différentes de l'échantillon de test partagée par @Hank D
    Il est évident que le prédicat de la forme u -> exp1 && exp2 est performant dans tous les cas.

    one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=3372, min=31, average=33.720000, max=47}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9150, min=85, average=91.500000, max=118}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9046, min=81, average=90.460000, max=150}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8336, min=77, average=83.360000, max=189}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9094, min=84, average=90.940000, max=176}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10501, min=99, average=105.010000, max=136}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=11117, min=98, average=111.170000, max=238}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8346, min=77, average=83.460000, max=113}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9089, min=81, average=90.890000, max=137}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10434, min=98, average=104.340000, max=132}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9113, min=81, average=91.130000, max=179}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8258, min=77, average=82.580000, max=100}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9131, min=81, average=91.310000, max=139}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10265, min=97, average=102.650000, max=131}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8442, min=77, average=84.420000, max=156}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8553, min=81, average=85.530000, max=125}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8219, min=77, average=82.190000, max=142}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10305, min=97, average=103.050000, max=132}
    InformationsquelleAutor Venkat Madhav