【Traduction】Quelques expériences d'écriture de tests de référence en Java

Parfois, nous avons besoin d'écrire du code de test de performances simple, et j'ai vu une expérience sur stackoverflow, comment écrire des tests de référence pour protéger autant que possible l'impact de l'environnement.

Traduit et publié ici :

Conseils pour rédiger des microbenchmarks de l'auteur de Java HotSpot :

Règle 0 : Lisez de bons articles sur les JVM et les microbenchmarks. Par exemple. N'attendez pas beaucoup de ces tests ; ils ne fournissent qu'une mesure limitée des performances de la JVM.

Règle 1 : Incluez toujours une phase d'échauffement qui s'exécute jusqu'à ce que toutes les initialisations et compilations soient déclenchées. (Le nombre d'itérations dans la phase d'échauffement peut être réduit, la règle empirique est de plusieurs dizaines de milliers de boucles.)

Règle 2 : toujours exécuter avec des paramètres tels que -XX:+PrintCompilation, -verbose :gc, etc., afin que la phase de compilation puisse être déterminée et que d'autres parties de la JVM effectuent un travail inattendu pendant le timing.

Règle 2.1 : Imprimez des messages au début et à la fin des phases de chronométrage et d'échauffement, afin que vous puissiez déterminer s'il y a une sortie de la règle 2 pendant le chronométrage.

Règle 3 : Comprenez la différence entre -client et -server, et la différence entre OSR et l'assembly régulier. -server est meilleur que -client, la compilation régulière est meilleure que OSR

Règle 4 : Faites attention à l'impact de l'initialisation, n'imprimez pas les résultats pour la première fois, sauf si c'est pendant le processus de chargement de la classe de test , La règle 2 est que vous vous battez contre cela. La première ligne de défense pour l'efficacité.

Règle 5 : Faites attention aux effets de l'optimisation et de la recompilation du compilateur. N'utilisez aucun chemin de code lors du timing, car le compilateur peut optimiser sur la base de certaines hypothèses optimistes telles que le chemin n'est pas utilisé du tout, permettant au code d'être supprimé et recompilé. La règle 2 est votre première ligne de défense contre cet effet.

Règle 6 : Utilisez les outils appropriés pour lire le fonctionnement du compilateur et faire du bon travail en produisant du code étonnant à partir de celui-ci. Vérifiez le code vous-même avant de formuler une théorie sur ce qui rend les choses plus rapides ou plus lentes.

Règle 7 : Réduire le bruit dans les mesures. Exécutez le benchmark sur une machine silencieuse et exécutez-le plusieurs fois, en éliminant les valeurs aberrantes. Utilisez -Xbatch pour sérialiser le compilateur avec l'application et envisagez de définir -XX:CICompilerCount=1 pour empêcher le compilateur de s'exécuter en parallèle avec lui-même.

Règle 8 : utilisez une bibliothèque pour l'analyse comparative car elle peut être plus efficace. Tels que JMH, Caliper, UCSD Benchmarks pour Java, etc.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!