-
Par Jean-Philippe BEMPEL (archi perf chez Ullink)
-
Twitter technique donné : @jpbempel
Règles empiriques : gaffe ! On les applique sans savoir pourquoi, on les hérite des "anciens du projet"…
→ Toujours les vérifier !
Le JIT permet à l’heure actuelle d’éviter bon nombre de ces vieilles règles.
→ Exemple du toArray() : gaffe ! Malgré ce qu’on pourrait croire, entre les solutions 2 et 3, c’est la 2 la plus rapide (pas besoin d’initialiser les éléments du tableau à 0 dans ce cas)
Le JIT marche beaucoup par pattern matching (reconnaissance de patterns de codage)
Voir les règles de codage de JRebel : https://www.jrebel.com/resources/java-resources#Java-Cheat-Sheets
De nouveau la comparaison entre LinkedList et ArrayList, en o(k1 *n) et o(k2 * n) MAIS avec k1 > k2 du fait du cache de nos procs modernes (voir les conf de Forax et Paumard sur le sujet)
→ En gros, morale de l’histoire : les constantes COMPTENT
(Et utilisez des ArrayList !)
|
📎
|
La latence mémoire permet de catégoriser les problèmes de perf que l’on rencontre (30 ms ce n’est PAS un pb de cache…) |
→ Mais on s’est fait piéger !
Tout ça pour un exemple où on fait une requête en base SANS index, qui est BIEN plus lente (ordre de grandeur) qu’un pb de DCL.
Micro-benchmarks are really hard to make it correct.
|
❗
|
Utilisez JMH ! Toujours ! Et rien d’autre ! |
→ Mais même avec, soyez prudents !
Le micro-benchmark implique un espace de travail TRES restreint, qui ne correspond PAS à la réalité !
|
💡
|
Conseil de JP
: préférez des macro benchmark avec des données réelles.
|
Premature optimization is the root of all evil !
Measure, don’t guess !
Measure, don’t premature !
