Protocole de test

Lorsque l'on fabrique des micro-benchmarks, l'ennemi c'est HotSpot. Pour ceux qui voudraient s'y frotter, je vous conseille à ce sujet l'exellemnt article (en anglais) : Anatomy of a flawed microbenchmark.

En effet le bougre est tellement doué qu'il a vite fait de fausser les résultats par un tour de passe-passe en détectant que telle ou telle partie de code n'est pas utilisée. Tous les tests qui sont fait ici sont donc clôturés par un test de sorte à s'assurer qu'HotSpot ne nous joue pas de tours.

De plus pour réduire encore les aléas, chaque benchmark est lancé 10 fois de suite et seul le meilleur résultat est gardé (merci shimrod . A chaque lancement de test, le garbage collector est vidé (autant que faire se peut), et les cache disques sont ré-initialisés.

Enfin, tout se fait de manière automatique dans une infrastructure maison très proche de JUnit de sorte à ne privilégier personne. Les graphiques sont ainsi générés automatiquement à l'issue de chaque test.

Influence du -server

Tant que l'on est dans le domaine de HotSpot, il est intéressant de jeter un œil sur une optimisation des plus directe, à savoir d'utiliser la VM dans son profil "serveur". Pour ce test, un calcul de la valeur de PI à 100 chiffres sert de base de travail et le résultat est pour le peu étonnant.

Le mode -server indique à la VM, et particulièrement à HotSpot, d'optimiser dès le démarrage tout ce qu'il peut. Ce à quoi cela correspond exactement reste assez obscur, certains disent qu'HotSpot pré-compile l'ensemble du code, d'autres qu'il détecte les chemins efficaces en avance de phase (c'est à dire avant d'avoir à les exécuter réellement). Au fond peu importe, ce qui est sûr c'est que les performances sont meilleures avec cependant une contrepartie à garder en tête.

Sur le graphique, les barres indiquent les temps d'exécution du calcul de PI pour les deux modes, la ligne représente elle le temps de démarrage par mode. Ce que l'on constate donc c'est que si le gain de performance est réel, le temps d'exécution lui, a augmenté significativement. C'est donc la première contre-partie. La seconde étant que ce mode est réputé consommer plus de mémoire.

En somme, le mode "server" est bien adapté à des applications aillant une longue durée de vie. Les applications devant démarrer vite et avec peu de mémoire préféreront le mode "client".

Copie de tableau

Cette vieille histoire de copie de tableaux est une bonne manière d’illustrer les évolutions qu'à connues la VM depuis ces débuts. En effet, la bonne réputation de System.arrayCopy s’est faite à l’époque du JDK 1.4 où elle obtenait des scores deux à trois fois supérieurs à une recopie par itérative.

Avec les JDK 6 et 7 (graphique ci-contre) les choses ont bien changé. ArrayCopy reste rapide mais la différence est devenue très faible alors que le test porte tout de même sur un tableau de 20 millions d'entiers de type long... L'autre aspect intéressant de ce résultat est que System.arrayCopy est une méthode native, c'est à dire écrite en C. Cela illustre donc assez bien les différences réelles de performance entre une VM moderne et un code compilé nativement.

Entrées/Sorties

Dés qu’il s’agit d'entrées-sorties, que ce soit pour un fichier ou pour un flux réseau, la règle d’Or est « tampon ». Certains vont trouver cela un peu naïf comme conseil mais la réalité du code que j’ai régulièrement sous les yeux tend à prouver que ce n’est pas une évidence pour tous et les cas de lecture ou écriture dans un input/output stream tout con, et ce tant qu'à faire, octet par octet, sont légions. Le graphique ci-contre donne une bonne idée de l’impact de cette approche sur les performances.

La raison est toute simple. Nombre de périphériques fonctionnent par bloc, et donc par tampon. Forcer une lecture-écriture octet par octet sur un disque où une interface réseau revient à court-circuiter ce mécanisme en obligeant le matériel à vider des tampons quasi vides. Et se traduit par une perte drastique de performance.

La solution la plus simple consiste à systématiquement encapsuler un input/output stream dans un BufferedInputStream ou BufferedOutputStream.

Ensuite il est possible d'améliorer encore les performances en utilisant la librairie NIO disponible depuis le JDK 1.4. Comme vous les voyez les résultats sont très bon mais le code beaucoup plus complexe.

D'un point de vue général, la bonne position est de toujours passer par un buffer, et autant que possible écrire par block dans ce buffer

Méthodes finales

Toute personne à qui j'ai demandé à quoi servait le mot clef final a du me sortir une version différente de l'histoire. Dés fois c'est juste "joli", d'autre cela fait gagner de la mémoire, cela protège les fonctions/classes, d'autre fois encore cela rend tout plus rapide. Après avoir pas mal cherché car moi non plus je n'avais pas la réponse, je me suis rendu compte que c'est le camp de la "mémoire" qui avait raison, avec celui de la protection, un peu. Mais pour la performance, comme vous pouvez le constater, ça change que dalle...

Position de la constante dans un test

Je ne sais pas de quant date cette drôle de mode, sûrement des âges lointains du C, mais j'ai rencontré un nombre de fois incalculable des développeurs qui s'acharnaient à écrire des choses comme

L'argument auquel j'ai souvent eu droit est que cette approche est beaucoup plus performante pour une raison obscurément liée au nombre de la bête. Mais comme en témoigne le graphique, c'est un mythe cyberurbain de plus. La position de la constante n'a aucune sorte d'importance et ce serait autrement lisible par un humain de base si s'était écrit dans le "bon" sens.

Il en va de même pour les fanatiques du ++compteur qui n'apporte strictement rien sur le naïf compteur++ lisible par n'importe quel quidam, moi compris. pour info, le test a été répété 5 millions de fois pour obtenir ce pouillème de différence sûrement due à un ou deux quarks en vadrouille sur mon CPU ce jour là.

Les exceptions

Là ce n'est plus un mythe, ou plutôt ce n'en était pas un. En effet, les blocks try/catch ont souvent été à juste titre pointés comme une source de fuite de performance. Et force est d'avouer que la VM a énormément évolué depuis pour obtenir aujourd'hui d'aussi une si petite différences sur des tests itérés 1 million de fois...

En somme, si votre programme broute, ce n'est pas la peine de virer la gestion des exceptions...

Condition d'une boucle

Autant la position d'une constante dans un test n'a, comme nous l'avons vu, strictement aucune incidence sur les performances, autant la condition dans une boucle de type for ou while peut avoir des conséquences désastreuses. Et c'est au fond une question de bon sens car cette condition est exécutée autant de fois que la boucle fait de tous. Ainsi, si vous écrivez une boucle comme dans l'exemple suivant, à chaque itération, la fonction calculeValeurMax est exécutée.

Et si cette fonction prend disons 50ms à renvoyer son résultat, une boucle de 1000 itérations, coûtera 50 secondes juste pour le test... La solution est dans ce cas d'inverser la tendance pour placer la fonction coûteuse dans une zone fixe.

Taille des identifiants

Repassons un peu sur de la bonne légende urbaine maintenue vivace par la guilde des compresseurs de code. Cette catégorie de gens ont un métier qui s'approche plus de la cryptographie que du développement tant ils aiment à produire un code bien compact en persuadant leur entourage que plus c'est court, plus ça va vite. Ces gens là, on les comprend, détestent les formateurs automatique de code et se vengent sur la taille des identifiants en les réduisant au maximum à un ou deux caractères arguant que de longues variables influent sur les performances.

Dans l'exemple du graphique, j'ai une variable qui fait à peu prés 255 caractères contre une de 1 caractère. Comme vous le voyez, sur 500 millions d'itérations la différence est flagrante... Et pour cause, le compilateur Java stocke les identifiants, toutes tailles confondues, dans un dictionnaire en tête du bytecode de la fonction et ne les utilise plus que par référence en interne. Il n'y a donc aucune raison autre que religieuse à produire un code illisible ou utiliser des abréviations compréhensible des seuls initiés.

Objets mutables et immutables

Un objet est dit "immutable" si l'on ne peut pas en changer la valeur interne. Par exemple String est immutable. Si l'on veut changer la chaîne de caractère qu'il contient nous sommes obligés de créer un nouvel objet. A contrario, StringBuffer est un objet mutable. Je peux le vider de son contenu ou l'étendre.

Une des raisons des gros problèmes de performances de Swing à ces débuts tenait justement à ce que des objets élémentaires comme Point ou Dimension étaient immutable, obligeant ainsi la VM à créer des objets en pagaille à chaque modification. Aujourd'hui la coordonnées X d'un point est modifiable par p.x avec du coup un réel gain de performance.

Le graphique ci-contre illustre la différence d'approche mutable/immutable pour donner une idée des différences de performance. L'immutabilité est donc à utiliser avec parcimonie lorsqu'elle est réellement justifiée (intégrité du contenu par exemple).

Synchronisation

La synchronisation est un mécanisme permettant à une même ressource d'être utilisée sans conflits par plusieurs processus (thread). Ainsi lorsqu'un traitement est synchronisé sur un objet, cet objet n'est disponible que pour le premier arrivant, les suivants sont mis en attente jusqu'à ce que la ressource soit libérée, et ainsi de suite.

Les blocs synchronisés, comme les Exceptions vues plus haut, ont longtemps été une source de perte de performance en Java. Il y a donc dans le JDK des versions synchronisées (dits thread-safe) et non-synchronisées pour une même fonction. C'est le cas de Hashtable (synchronisé) et Hashmap (non synchronisé), Vector (synchronisé) et ArrayList (non synchronisé).

Il serait donc logique de se dire qu'il est important d'utiliser les versions non-synchronisées aussi souvent que possible. Mais le problème est qu'avec une VM moderne (JDK6/7), comme pour les Exceptions, les blocs synchronisés représente un coût négligeable. Le graphique ci-contre en témoigne et le nombre d'itération utilisé pour le construire est de 1 million...

Or aujourd'hui, avec le développement massif des processeurs à 2 ou 4 cœurs, les applications gagnent réellement à être massivement parallélisées. Utiliser une structure qui ne soit pas "thread safe" c'est prendre le risque de passer des heures à chercher les verrous mortels lorsque vous serez amenés à "threader" votre code.

Le second graphique d'exemple compare justement un Hashmap de 800 milles éléments à ses équivalents Hashtable et ConcurrentHashmap. Comme vous le voyez, le jeu n'en vaut clairement plus la chandelle avec même une petite avance pour ConcurrentHashmap. Et le résultat est strictement le même entre Vector et ArrayList.

Alors vu l'enfer que représente d'un debuggage multi-thread, pensez-y à deux fois avant de jouer la carte de ce genre d'optimisation.

Les entiers

Une idée communément répandue est de dire que plus petite est la structure, meilleur sont les performances. Ainsi il est courant de voir des compteurs de boucles "taillées au plus juste", genre en utilisant un byte. Le problème est que dans la vraie vie les choses se passent autrement car c'est la matériel qui compte. Et il y a longtemps que les CPU ne manipulent plus des entiers de 8bits, mais plutôt de 32 ou 64 bits. La conséquence est que pour les opérations de comptage (Inc/Dec et Add/Sub), le byte est systématiquement le mauvais choix de performance et int le meilleur alors qu'il est 4 fois plus gros. Et pour les mêmes raisons sur les processeur modernes, un long (64 bits) est toujours et encore meilleur qu'un byte.

A noter aussi que les opérateurs ++ et -- sont plus rapides que leurs équivalent +1 et -1. La aussi la raison en est que les processeurs disposent d'opérateurs d'incrémentation-décrémentation et que le bytecode, lui aussi, distingue ces deux cas. Du coup, sur un processeur moderne décrémenter ou incrémenter un compteur est à peu prés aussi performant sur un long que sur un int.

Maintenant il y a une autre raison beaucoup plus intéressante qui se trouve dans le bytecode lui-même. Prenons l'incrémentation d'une variable de type entier (i++), en byte code cela nous donne :

Maintenant regardons le bytecode de l'incrémentation d'un byte (b++)

Étonnant non ? En fait lorsqu'une seule opération est nécessaire pour incrémenter notre entier, il en faut 5 pour incrémenter un byte.

Variables locales contre champs

Là aussi c'est un concept qui revient souvent. La variable locale serait plus rapide que la variable d'instance (le champ). Et pourtant, comme vous pouvez le voir, la différence est loin d'être flagrante et ce même en poussant à 1 milliard d'itérations. Même constat lorsque les variables sont finales ou statiques, cela ne change rien du tout.

Getter ou pas getter

Les accesseurs (getters et setters) emmerdent les développeurs, c'est bien connu Et pourtant ils ont une importance primordiale car ils offrent sécurité et extensibilité. En effet, il est autrement plus simple d'ajouter des tests sur un setValeur() que sur un champ public que l'on a laissé "filé" dans la nature.

Mais comme souvent cette bonne pratique est contrée par des impératifs de performance. Le Getter ou le Setter, c'est un appel de fonction et donc un temps en plus qui va plomber l'application...

En vérité c'est bien mal connaître M. HotSpot, le compilateur temps réel de Java, qui va arranger tout cela aux petits oignons pour obtenir les résultats du graphique qui se passent de commentaires. L'argument performance ne tient ici pas la route, le résultat est strictement le même.

Les dimensions des tableaux

Encore une légende urbaine qui a la peau dure : plus un tableau a de dimensions, plus ça rame. Là aussi ce doit être un héritage que nous a laissé l'ancêtre C mais la réalité Java est tout autre. Le nombre de dimension n'a juste aucun impact sur les temps d'exécution. Donc autant faire rapidement un code propre plutôt que de se perdre dans des buffer[y*largeur+x] qui eux, coûtent du temps (celui du calcul de l'indice).

Chaînes de caractère

Comme nous l'avons vu plus haut, les String sont immutables, ce qui implique que lorsque l'on cherche à construire dans une boucle, une liste de 100 items séparés par des virgules, nous fabriquons en réalité au minimum 100 objets String. 200 même si les deux ajouts sont séparés. Autant dire que lorsqu'il s'agit de modifier une chaîne, comme l'illustre sans appel le graphique, il faut systématiquement passer par un StringBuffer qui est fait pour cela.

L'exemple suivant est plus étonnant. Il s'agit de formater une chaîne composée d'un entier, une espace et une autre chaîne. Je me suis longtemps fait avoir en imaginant que le très pratique String.format("%d %s", i, PATTERN) était plus performant que i+" "+PATTERN. Belle erreur comme en témoigne le graphique ou les deux derniers cas font appel à ce fameux formateur. La concaténation à l'ancienne est donc préconisée lorsque l'on a aucun formatage évolué à mettre en œuvre.

Cast et Generics

Les génériques étaient une évolution très attendue du JDK 1.5 permettant de typer un objet lors de son utilisation (Vector<Integer>). Il était donc intéressant de savoir si cette fonctionnalité avait un coût en terme de performance. Et le résultat semble être que non.

Et ce n'est pas si étonnant au fond car sans les génériques, nous étions obligés d'opérer un cast sur les valeurs d'un Vector par exemple pour pouvoir utiliser l'objet sous-jacent.

Avec les génériques ce cast est, un peu comme le C++, effectué à la compilation du code. Le gain entre les deux approches est donc à mettre au crédit de cet aspect comme en témoigne le second graphique qui mesure l'impact d'un cast sur le temps d'exécution.

Notez au passage que le cast classique (MonObjet)maValeur et par méthode MonObjet.class.cast(maValeur) ont le même coût.

Avec les génériques ce cast est, un peu comme le C++, effectué à la compilation du code. Le gain entre les deux approches est donc à mettre au crédit de cet aspect comme en témoigne le second graphique qui mesure l'impact d'un cast sur le temps d'exécution.

Notez au passage que le cast classique (MonObjet)maValeur et par méthode MonObjet.class.cast(maValeur) ont le même coût.

AutoBoxing

Lorsque l'on manipule les versions Objet de types de base, comme Integer, une optimisation qui est souvent évoquée est de replacer Integer i=new Integer(2) par Integer i=Integer.valueOf(2). Sur le graph, on se rend bien compte que la différence est, comment dire, assez négligeable... Mais ce qui est ici intéressant c'est que l'utilisation de l'AutoBoxing, c'est à dire quelque chose du genre Integer i=2, qui est une fonctionnalité apparue avec la version 1.5 de Java, est aussi rapide que les autres.

Conclusion

Ce qu'il faut conclure de tout cela est tout d'abord que la VM a énormément évolué, gommant beaucoup de problèmes de performances (synchronisation, Exceptions, etc.). Ensuite que le code offusqué n'est en rien plus performant qu'un code clair. Enfin, qu'outre deux trois fondamentales comme l'utilisation des buffers (String ou IO) ou l'utilisation des entiers, aucune optimisation n'est réellement efficace. La meilleure manière d'optimiser reste d'écrire un code le plus clair possible et de lasser HotSpot faire au mieux son travail. Doublé d'une bonne dose de bon sens, cela devrait permettre d'obtenir le maximum d'efficacité.