Comparer les performances entre les Java lambdas et les classes anonymes avec l'outil JMH,
Un tutoriel de Bruno Doolaeghe
Le 2016-10-27 11:49:22, par Mickael Baron, Rédacteur
SOAT, société d'expertise et de conseil en informatique, et Matthieu Lefèvre, vous propose un tutoriel pour comparer les performances entre les Java lambdas et les classes anonymes en utilisant JMH pour la phase de benchmark.
Voici l'URL du tutoriel : http://soat.developpez.com/tutoriels...classeanonyme/
Si vous avez des commentaires, profitez de cette discussion
Merci d'avance
L'équipe Java
Retrouver les meilleurs cours et tutoriels pour apprendre Java : http://java.developpez.com/cours/
Voici l'URL du tutoriel : http://soat.developpez.com/tutoriels...classeanonyme/
Si vous avez des commentaires, profitez de cette discussion
Merci d'avance
L'équipe Java
-
Philippe BastianiMembre éprouvéPetite coquille dans la conclusion : Arrays.parallelSort utilise bien l'API fork-join ! et puis les Lambdas utilisent déjà invokeDynamic !
Arrays.parallelSort(), Stream.parallel() CompletableFuture, etc utilisent un pool de thread fork-Join par défaut dont le nombre de threads possibles est dépendant de Runtime.getRuntime().availableProcessors ! L'auteur utilise un i5-2500K avec 4 CPUs et 4 threads/CPU... par défaut le nombre de threads pour la // sera égal à 15 (i.e. 4x4 -1 sachant qu'un thread reste réservé pour l'appelant)...
Arrays.parallelSort() s'appuie sur ForkJoinPool.getCommonPoolParallelism() pour déterminer si la // doit être effective: bref sur dual core (et biensûr un single core) aucune chance d'avoir une quelconque // !
Par défaut nous disposons d'un seul pool de thread fork-join : donc les performances vont être dépendantes du nombre de tâches à paralléliser.
En se qui concerne l'API stream les résultats vont aussi être dépendants de la source de données (par exemple, à la différence d'un Array, une LinkedList se prêtera mal à la // - il en sera de même pour une source de flux I/O - etc). Attention aussi aux opérations longues lors d'une //... de telles opérations seront pénalisantes et le résultat risque fort d'être décevant. Au final Stream.parallel() est facile d'utilisation; mais les résultats sont souvent décevants
a+
Philippele 28/10/2016 à 0:17 -
Bruno DOOLAEGHENouveau Candidat au ClubBonjour Philippe,Petite coquille dans la conclusion : Arrays.parallelSort utilise bien l'API fork-join ! et puis les Lambdas utilisent déjà invokeDynamic !
(...) l'apparition dans le JDK 8 du tri parallèle sans fork/join pool, par la méthode Arrays.parallelSort()
Néanmoins, les expressions lambda étant encore bien jeunes dans le monde Java, on est en droit d'espérer des optimisations notables sur leur invocation, dans les prochaines versions de JVM (optimisations qui seront prises en compte dynamiquement, sur un bytecode Java déjà « lambda ready », grâce à l'utilisation d'invokeDynamic !).
Enfin, je suis d'accord sur le fait que même si les API facilitent grandement le travail de découpage et d’exécution d'un traitement en parallèle, elles ne nous dispensent pas de résoudre les problèmes classiques liés à la parallélisation (tels que les goulots d'étranglement)le 29/10/2016 à 15:16 -
Pill_SMembre expertAprès une première lecture, je me suis dit "tiens, mais en fait les différences sont vraiment minimes voir insignifiantes..."
Ensuite, j'ai remarqué que l'échelle était logarithmique... Et ça, ça change tout
Du coup, je me demande si ce serait pas mieux d'avoir une échelle normale (quitte à découper les graphiques en morceaux plus petits)? ça rendrait l'interprétation plus naturelle...le 24/11/2016 à 17:05