IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Comparer les performances entre les Java lambdas et les classes anonymes avec l'outil JMH,
Un tutoriel de Bruno Doolaeghe

Le , par Mickael Baron
3 commentaires

59PARTAGES

5  0 
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/
Vous avez lu gratuitement 23 413 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

3 commentaires
Commenter Signaler un problème
Philippe Bastiani
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 28/10/2016 à 0:17
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+
Philippe
0  0 
Bruno DOOLAEGHE
Avatar de Bruno DOOLAEGHE
Nouveau Candidat au Club https://www.developpez.com
Le 29/10/2016 à 15:16
Bonjour Philippe,

Petite coquille dans la conclusion : Arrays.parallelSort utilise bien l'API fork-join ! et puis les Lambdas utilisent déjà invokeDynamic !
Sur le fond, nous sommes d'accord. Ce qu'il fallait comprendre dans la conclusion :


(...) l'apparition dans le JDK 8 du tri parallèle sans fork/join pool, par la méthode Arrays.parallelSort()
En effet, fork/join est utilisé dans Arrays.parallelSort() ... Ce que je voulais dire par là, c'est que désormais l'écriture du fork/join n'est plus à la charge du développeur qui souhaite faire un tri parallélisé ; elle est encapsulée dans la méthode Arrays.parallelSort() du JDK8.

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 !).
InvokeDynamic est effectivement déjà utilisé quand on écrit une lambda. Ce qu'il fallait comprendre ici, c'est que c'est grâce à cela que les futures optimisations de la JVM (sans changement sur le SDK) pourront voir le jour.

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)
0  0 
Pill_S
Avatar de Pill_S
Membre expert https://www.developpez.com
Le 24/11/2016 à 17:05
Aprè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...
0  0