Cela faisait longtemps que je n’avais pas \u00e9crit un article de blog et pourtant, pour cause de confinement, j’ai du temps pour le faire!<\/p>\n
N’ayant pas d’id\u00e9e, j’ai demand\u00e9 \u00e0 ma twitosph\u00e8re de m’en donner, et j’ai eu une r\u00e9ponse int\u00e9ressante :<\/p>\n
\nLes diff\u00e9rences de perf entre stream et for classique ? On en a parl\u00e9 y’a longtemps, mais j’avais fait une session de micro bench avec JMH qui montrait que les ‘for’ \u00e9taient plus performants que les streams.<\/p>\n\u2014 J\u00e9r\u00e9my Thulliez (@JeremyThulliez) April 14, 2020<\/a><\/blockquote>\nhttps:\/\/platform.twitter.com\/widgets.js<\/a>\n
Voici donc un article parlant des diff\u00e9rences de performance entre une boucle for et un Stream Java.<\/p>\n
Tout d’abord, parlons un peu de benchmark. Comme on veut comparer les performances d’une boucle for et des Stream en Java, il nous faut un outil qui permet de r\u00e9aliser des micro-benchmarks de mani\u00e8re pertinente. En effet, quand on r\u00e9alise des micro-benchmarks, on peut rencontrer pas mal de soucis quand ce que l’on veut mesurer est en dessous de la dizaine de microsecondes : un simple passage d’un garbage collector par exemple peut rendre la mesure inop\u00e9rante. Il faut aussi correctement pr\u00e9-chauffer la JVM pour tenir compte de l’effet du Just In Time Compiler (le JIT), sans parler de mesurer correctement le temps (et non,
System.currentTimeInMillis()<\/code> n’est pas l\u2019apanage ici).<\/p>\nPour parer \u00e0 tous ces soucis, il n’y a qu’une seule solution, JMH – The Java Microbenchmark Harness<\/a>. Cet outil nous permet d’\u00e9crire des micro-benchmarks pertinents en tenant compte des caract\u00e9ristiques internes de la JVM. Il offre aussi des outils int\u00e9gr\u00e9s pour analyser les performances de nos tests (profiler, disassembler, …). Si vous ne connaissez pas JMH, vous pouvez vous r\u00e9f\u00e9rez \u00e0 cet article : INTRODUCTION \u00c0 JMH \u2013 JAVA MICROBENCHMARK HARNESS<\/a>.<\/p>\n
Tous les tests ont \u00e9t\u00e9 ex\u00e9cut\u00e9s sur mon laptop : Intel(R) Core(TM) i7-8750H 6 coeurs (12 avec hyperthreading) – Ubuntu 19.10.<\/p>\n
Benchmark 1 : \u00e0 vide<\/h2>\n
Pour notre premier test, comparons les performances \u00e0 vide<\/em> via un test le plus simple possible, que l’on va ex\u00e9cuter sur une liste \u00e0 taille variable (10, 1 000, 10 000 \u00e9l\u00e9ments).<\/p>\n
\n \/\/ the test will be done for 10, 1000 and 10000 elements\n @Param({\"10\", \"1000\", \"10000\"}) \n int size;\n\n List\n list;\n\n @Setup\n public void setup() { \/\/ we setup the test with the test data\n list = new ArrayList(size);\n for (int i = 0; i bh.consume(i));\n }\n<\/pre>\nQuand on lance un benchmark via JMH, le warning suivant est affich\u00e9, merci d’en tenir compte ;)<\/p>\n
\nREMEMBER: The numbers below are just data. \nTo gain reusable insights, you need to follow up on why the numbers are the way they are. \nUse profilers (see -prof, -lprof), design factorial experiments, perform baseline and negative tests that provide experimental control, make sure the benchmarking environment is safe on JVM\/OS\/HW level, ask for reviews from the domain experts.\nDo not assume the numbers tell you what you want them to tell.\n<\/blockquote>\nEt voici les r\u00e9sultats en nanoseconde par op\u00e9ration (le plus bas est le meilleur) avec la JVM OpenJdk 11.0.5.<\/p>\n
\nForVsStream.testForLoop_doNothing 10 avgt 5 46,715 \u00b1 4,581 ns\/op\nForVsStream.testForLoop_doNothing 1000 avgt 5 4581,216 \u00b1 355,653 ns\/op\nForVsStream.testForLoop_doNothing 10000 avgt 5 45320,910 \u00b1 670,446 ns\/op\nForVsStream.testStream_doNothing 10 avgt 5 51,563 \u00b1 3,682 ns\/op\nForVsStream.testStream_doNothing 1000 avgt 5 3634,718 \u00b1 513,237 ns\/op\nForVsStream.testStream_doNothing 10000 avgt 5 36757,820 \u00b1 2956,085 ns\/op\n\n<\/pre>\nPour de petite valeur de liste, l’utilisation d’une boucle for est plus rapide, mais pour des valeurs plus importante (mais toujours assez petite), les Stream sont plus performants !<\/p>\n
La diff\u00e9rence pour la plus petite valeur d’it\u00e9ration s’explique facilement, l\u2019ex\u00e9cution d’un Stream n\u00e9cessite la cr\u00e9ation d’objets Java et celle-ci a un co\u00fbt qui est important au regard du co\u00fbt d’ex\u00e9cution quand il y a peu d’it\u00e9rations. Lancer le benchmark avec
-prof gc<\/code> (profiler int\u00e9gr\u00e9 \u00e0 JMH en mode garbage collection) permet de voir que pour 10 \u00e9l\u00e9ments on a quasiment aucune allocation m\u00e9moire pour une boucle for mais 192 Mo\/s d’allocation m\u00e9moire pour un Stream.<\/p>\nPar contre, pour un nombre d’it\u00e9rations plus grand, on n’a quasiment plus d’allocations m\u00e9moire et la diff\u00e9rence de performance au profit d’un Stream devient difficilement explicable. En regardant le code g\u00e9n\u00e9r\u00e9 par le JIT (via
-prof perfasm<\/code>) on peut voir qu’il y a beaucoup moins d’instructions g\u00e9n\u00e9r\u00e9es pour unforEach<\/code> de Stream que pour une boucle for, entre autre \u00e0 chaque tour de boucle for on fait un appel \u00e0ArrayList.next()<\/code> qui fait lui-m\u00eame un appel \u00e0ArrayList.checkForComodification()<\/code>. Je pense qu’en se basant sur des tableaux et pas des listes les r\u00e9sultats auraient \u00e9t\u00e9 diff\u00e9rents.<\/p>\nBenchmark 2 : somme de nombres<\/h2>\n
Testons maintenant avec une op\u00e9ration un peu plus complexe : on va r\u00e9aliser la somme des entiers de la liste. Comme on peut le faire de nombreuses mani\u00e8res diff\u00e9rentes avec les Stream on va en tester deux : un
reduce<\/code> et unmapToInt<\/code> (qui transforme en IntStream) suivi d’unsum<\/code>.<\/p>\n\n @Benchmark\n public int testForLoop_Accumulation() {\n int acc = 0;\n for (Integer i : list) {\n acc += i;\n }\n return acc;\n }\n\n @Benchmark\n public Integer testStream_AccumulationByMap() {\n return list.stream().mapToInt(Integer::valueOf).sum();\n }\n\n @Benchmark\n public Integer testStream_AccumulationByReduce() {\n return list.stream().reduce(0, Integer::sum);\n }\n<\/pre>\nEt voici les r\u00e9sultats :<\/p>\n
\nForVsStream.testForLoop_Accumulation 10 avgt 5 12,960 \u00b1 0,809 ns\/op\nForVsStream.testForLoop_Accumulation 1000 avgt 5 749,318 \u00b1 14,473 ns\/op\nForVsStream.testForLoop_Accumulation 10000 avgt 5 6679,846 \u00b1 81,442 ns\/op\nForVsStream.testStream_AccumulationByMap 10 avgt 5 51,954 \u00b1 3,562 ns\/op\nForVsStream.testStream_AccumulationByMap 1000 avgt 5 4638,615 \u00b1 394,359 ns\/op\nForVsStream.testStream_AccumulationByMap 10000 avgt 5 52717,408 \u00b1 4893,117 ns\/op\nForVsStream.testStream_AccumulationByReduce 10 avgt 5 33,495 \u00b1 2,197 ns\/op\nForVsStream.testStream_AccumulationByReduce 1000 avgt 5 5635,545 \u00b1 476,337 ns\/op\nForVsStream.testStream_AccumulationByReduce 10000 avgt 5 43167,492 \u00b1 3646,626 ns\/op\n<\/pre>\nL\u00e0 on a une diff\u00e9rence flagrante entre une boucle for et l’utilisation d’un Stream : avec 10000 \u00e9l\u00e9ments la boucle for est quasiment 10x plus rapide! Ce qui est int\u00e9ressant c’est que les deux impl\u00e9mentations avec les Stream offrent des performances similaires.\nQuand on regarde les allocations m\u00e9moire, on a pour le coup \u00e9norm\u00e9ment d’allocations m\u00e9moire pour 1000 et 10000 \u00e9l\u00e9ments pour les Stream (environ 35O Mo\/s et 425 Mo\/s pour le mapToInt, 30% moins pour le reduce).<\/p>\n
Apparemment, c’est bien la cr\u00e9ation d’objet interm\u00e9diaire n\u00e9cessaires pour les op\u00e9rations sur les Streams qui impacte les performances.<\/p>\n
Le JIT Graal est cit\u00e9 comme ayant des optimisations plus pouss\u00e9es sur les Stream, lan\u00e7ons donc le benchmark avec Graal au lieu du JIT par d\u00e9faut d’OpenJDK : C2.\nJ’ai utilis\u00e9 GraalVM 19.3.1-java11 pour plus de simplicit\u00e9 mais on peut utiliser le JIT Graal avec OpenJDK.<\/p>\n
\nForVsStream.testForLoop_Accumulation 10 avgt 5 25,960 \u00b1 1,414 ns\/op\nForVsStream.testForLoop_Accumulation 1000 avgt 5 2422,501 \u00b1 385,645 ns\/op\nForVsStream.testForLoop_Accumulation 10000 avgt 5 25197,850 \u00b1 6781,623 ns\/op\nForVsStream.testStream_AccumulationByMap 10 avgt 5 50,210 \u00b1 3,361 ns\/op\nForVsStream.testStream_AccumulationByMap 1000 avgt 5 1601,862 \u00b1 53,173 ns\/op\nForVsStream.testStream_AccumulationByMap 10000 avgt 5 15947,271 \u00b1 759,564 ns\/op\nForVsStream.testStream_AccumulationByReduce 10 avgt 5 35,362 \u00b1 8,530 ns\/op\nForVsStream.testStream_AccumulationByReduce 1000 avgt 5 4279,177 \u00b1 151,122 ns\/op\nForVsStream.testStream_AccumulationByReduce 10000 avgt 5 43256,515 \u00b1 1942,682 ns\/op\n<\/pre>\nGraal semble optimiser beaucoup mieux l’impl\u00e9mentation via mapToInt().sum() que C2, par contre les performances via une boucle for sont deux fois moins bonne.<\/p>\n
Comme on ne retrouve pas ces diff\u00e9rences sur les autres benchmarks (les r\u00e9sultats ne sont pas int\u00e9gr\u00e9s dans cette article mais sont tr\u00e8s proches).\nOn peut penser que c’est ici un probl\u00e8me \u00e9ph\u00e9m\u00e8re au moment du lancement du test, j’ai donc relanc\u00e9 le benchmark et j’ai toujours eu le m\u00eame r\u00e9sultat! Les boucles for sont moins bien optimis\u00e9es avec Graal. J’ai donc demand\u00e9 aux d\u00e9veloppeurs de Graal ce qu’ils en pensent, je mettrais \u00e0 jour l’article avec des explications si j’en ai ;) .<\/p>\n
@thomaswue<\/a> @shelajev<\/a> I make some microbenchmarks to compare performance of for loop vs Stream. I run them with C2 and Graal and saw some differences.
1. Trivial for loop that performs a sum of ints is 2x – 4x slower.
2. Stream that uses mapToInt().sum() is 3x quicker.
Results \u2b07\ufe0f<\/p>\u2014 Lo\u00efc Mathieu (@loicmathieu) April 20, 2020<\/a><\/blockquote>\nhttps:\/\/platform.twitter.com\/widgets.js<\/a>\nBenchmark 3 : concat\u00e9nation de String<\/h2>\n
Finissons par un exemple de concat\u00e9nation de String, celui-ci devrait \u00eatre moins sensible au probl\u00e8me de diff\u00e9rences de cr\u00e9ation d’objets entre une boucle for et un Stream.<\/p>\n
\n @Benchmark\n public String testForLoop_StringBuilder() {\n StringBuilder builder = new StringBuilder();\n for (Integer i : list) {\n builder.append(i.toString());\n }\n return builder.toString();\n }\n\n @Benchmark\n public String testStream_StringBuilderByForEach() {\n StringBuilder builder = new StringBuilder();\n list.stream().forEach(i -> builder.append(i.toString()));\n return builder.toString();\n }\n\n @Benchmark\n public String testStream_StringBuilderByJoining() {\n return list.stream().map(i -> i.toString()).collect(Collectors.joining());\n }\n<\/pre>\nEt voici les r\u00e9sultats :<\/p>\n
\nForVsStream.testForLoop_StringBuilder 10 avgt 5 148,218 \u00b1 11,181 ns\/op\nForVsStream.testForLoop_StringBuilder 1000 avgt 5 19277,681 \u00b1 524,130 ns\/op\nForVsStream.testForLoop_StringBuilder 10000 avgt 5 189820,108 \u00b1 39519,566 ns\/op\nForVsStream.testStream_StringBuilderByForEach 10 avgt 5 124,379 \u00b1 4,701 ns\/op\nForVsStream.testStream_StringBuilderByForEach 1000 avgt 5 19643,228 \u00b1 1296,197 ns\/op\nForVsStream.testStream_StringBuilderByForEach 10000 avgt 5 179761,808 \u00b1 17014,818 ns\/op\nForVsStream.testStream_StringBuilderByJoining 10 avgt 5 242,916 \u00b1 27,689 ns\/op\nForVsStream.testStream_StringBuilderByJoining 1000 avgt 5 19560,014 \u00b1 3750,284 ns\/op\nForVsStream.testStream_StringBuilderByJoining 10000 avgt 5 207933,016 \u00b1 17316,623 ns\/op\n<\/pre>\nEntre une boucle for et un forEach sur un Stream, les performances sont quasiment identiques. Quand on r\u00e9alise des op\u00e9rations non triviales, il n’y a quasiment aucune diff\u00e9rence de performance ente une boucle for et un Stream !<\/p>\n
Quand on utilise
Collectors.joining()<\/code>, les performances sont l\u00e9g\u00e8rement moins bonnes mais restent assez proches pour un nombre important d’it\u00e9rations.<\/p>\nConclusion<\/h2>\n
La diff\u00e9rence de performance entre utiliser une boucle for et un Stream est quasiment n\u00e9gligeable en elle m\u00eame, ce qui change, c’est bien la nature des op\u00e9rations qu’on r\u00e9alise. Dans le cas des Stream, on peut facilement r\u00e9aliser beaucoup plus d’op\u00e9rations pour la m\u00eame t\u00e2che (exemple de la somme des nombres).<\/p>\n
Une des forces des Stream est de faciliter la cr\u00e9ation de pipeline d’op\u00e9rations : \u00e0 nous de faire attention et d’\u00eatre pragmatique dans son utilisation !<\/p>\n
Pour finir, je tiens \u00e0 rappeler que ce sont des micro-benchmarks : bien souvent, dans un cas r\u00e9el d’application, le pipeline d’op\u00e9rations sera beaucoup plus grand et donc la diff\u00e9rence de performance n\u00e9gligeable. Quand on prend en compte les optimisations du JIT et la lisibilit\u00e9 du code, bien souvent, utiliser un Stream est la meilleur solution ;)<\/p>\n
Pour ceux qui voudraient jouer avec le benchmark, il est disponible ici : https:\/\/github.com\/loicmathieu\/jmh-benchmarks\/blob\/master\/src\/main\/java\/fr\/loicmathieu\/jmh\/ForVsStream.java<\/a><\/a><\/p>\n
Un remerciement tout sp\u00e9cial \u00e0 Logan pour sa relecture et la correction des nombreuses fautes d’orthographe ;)<\/p>","protected":false},"excerpt":{"rendered":"
Cela faisait longtemps que je n’avais pas \u00e9crit un article de blog et pourtant, pour cause de confinement, j’ai du temps pour le faire! N’ayant pas d’id\u00e9e, j’ai demand\u00e9 \u00e0 ma twitosph\u00e8re de m’en donner, et j’ai eu une r\u00e9ponse int\u00e9ressante : Les diff\u00e9rences de perf entre stream et for classique ? On en a parl\u00e9 y’a longtemps, mais j’avais fait une session de micro bench avec JMH qui montrait que les ‘for’ \u00e9taient plus performants que les streams. \u2014…