{"id":1041,"date":"2020-04-29T10:35:00","date_gmt":"2020-04-29T08:35:00","guid":{"rendered":"https:\/\/www.loicmathieu.fr\/wordpress\/?p=1041"},"modified":"2020-12-01T19:57:48","modified_gmt":"2020-12-01T18:57:48","slug":"introduction-a-jmh-java-microbenchmark-harness","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/informatique\/introduction-a-jmh-java-microbenchmark-harness\/","title":{"rendered":"Introduction \u00e0 JMH – Java Microbenchmark Harness"},"content":{"rendered":"

Dans mon pr\u00e9c\u00e9dent article For vs Stream<\/a>, j’ai utilis\u00e9 JMH \u2013 The Java Microbenchmark Harness<\/a>, un outil pour r\u00e9aliser des microbenchmarks de mani\u00e8re facile, et surtout, pertinente.<\/p>\n

Cet article \u00e0 pour but de vous pr\u00e9senter l’outil et son utilisation.<\/p>\n

Mais tout d’abord : c’est quoi un microbenchmark ?<\/p>\n

Microbenchmark<\/h2>\n

Benchmark ou banc d’essai en fran\u00e7ais : un programme qui permet de mesurer les performances d’un syst\u00e8me, pour le comparer \u00e0 d’autres.<\/p>\n

Microbenchmark : un benchmark fait pour mesurer les performances d’une tr\u00e8s petite, et tr\u00e8s sp\u00e9cifique, portion de code.<\/p>\n

Le probl\u00e8me d’un microbenchmark est que sa pertinence est fortement li\u00e9e \u00e0 son environnement d’ex\u00e9cution, en Java : la JVM.<\/p>\n

En effet, celle-ci contient de nombreux composants (interpr\u00e9teur de code, Garbage Collector – GC, Just In Time Compiler – JIT, …), et r\u00e9alise de nombreuses optimisations au fil du temps, via le JIT principalement.<\/p>\n

Si on veut qu’un microbenchmark soit pertinent, il faut que les composants de la JVM ne viennent pas interagir avec la mani\u00e8re dont on ex\u00e9cute et mesure le benchmark.<\/p>\n

La mesure en elle-m\u00eame est fort complexe, si ce qu’on veut mesurer est proche de la milliseconde, alors un simple passage du GC peut la doubler. De plus, mesurer le temps n’est pas facile; si vous voulez plus d’information sur la mesure du temps en Java, voici un excellent article : Measuring time from Java to kernel and back<\/a>.<\/p>\n

Donc, r\u00e9aliser un microbenchmark via un simple Java main ou via un test JUnit n’est pas une bonne fa\u00e7on de faire. Comme utiliser System.currentTimeInMillis()<\/code>!\nIl nous faut un outil plus puissant, et qui sache s’interfacer avec les composants internes de la JVM.<\/p>\n

Cet outil, c’est JMH \u2013 The Java Microbenchmark Harness<\/a>, cr\u00e9\u00e9 par Aleksey Shipil\u00ebv<\/a>.<\/p>\n

Ecrire un microbenchmark avec JMH<\/h2>\n

Pour g\u00e9n\u00e9rer un projet, le plus simple est d’utiliser l’archetype Maven fournit par JMH.<\/p>\n

mvn archetype:generate \\\n          -DinteractiveMode=false \\\n          -DarchetypeGroupId=org.openjdk.jmh \\\n          -DarchetypeArtifactId=jmh-java-benchmark-archetype \\\n          -DgroupId=fr.loicmathieu.jmh \\\n          -DartifactId=jmh-benchmarks \\\n          -Dversion=1.0\n<\/pre>\n
Il g\u00e9n\u00e8re une classe MyBenchmark comme suit :<\/p>\n
import org.openjdk.jmh.annotations.Benchmark;\n\npublic class MyBenchmark {\n\n    @Benchmark\n    public void testMethod() {\n        \/\/ This is a demo\/sample template for building your JMH benchmarks. \n        \/\/ Edit as needed.\n        \/\/ Put your benchmark code here.\n    }\n\n}\n<\/pre>\n
Dans un projet JMH, on peut h\u00e9berger plusieurs groupes de benchmark, chacun dans sa propre classe.<\/p>\n
Prenons un exemple un peu plus complet, tir\u00e9 de mes tests For vs Stream :<\/p>\n
\npublic class ForVsStream {\n\n    @Param({\"10\", \"1000\", \"10000\"}) \/\/ \n    int size;\n\n    List list;\n\n    @Setup  \/\/ \n    public void setup() {\n        list = new ArrayList(size);\n        for (int i = 0; i < size; i++) { list.add(i); } \n    } \n\n    @Benchmark \/\/ \n    public void testForLoop_doNothing(Blackhole bh) {  \/\/ \n        for (Integer i : list) {\n            bh.consume(i);\n        }\n    }\n\n    @Benchmark  \/\/ \n    public int testForLoop_Accumulation() {\n        int acc = 0;\n        for (Integer i : list) {\n            acc += i;\n        }\n        return acc;\n    }\n}\n<\/pre>\n
  1. @Param<\/code> permet de param\u00e9trer le test. JMH va r\u00e9aliser une ex\u00e9cution de benchmark par valeur de param\u00e8tre (ici 3 fois).<\/li>\n\n
  2. @Setup<\/code> permet d’ex\u00e9cuter du code, une fois avant chaque ex\u00e9cution de benchmark, pour initialiser le benchmark (ici initialiser la liste). C’est tr\u00e8s important de n’inclure dans la m\u00e9thode de benchmark que le code que l’on veut mesurer, et d\u00e9porter dans une m\u00e9thode annot\u00e9e par @Setup<\/code> tout le code d’initialisation, sinon les r\u00e9sultats seront fauss\u00e9s.<\/li>\n\n
  3. @Benchmark<\/code> d\u00e9finit une m\u00e9thode de benchmark. On a donc ici 2 benchmarks diff\u00e9rents dans la m\u00eame classe de benchmark<\/li>\n\n
  4. Une des principales optimisations du JIT est l’\u00e9limination de code mort (Dead Code Elimination – DCE), pour \u00e9viter cela, JMH fournit une classe Blackhole<\/code> que l’on peut utiliser. Ici, si on n’avait rien fait dans le boucle for, le JIT aurait fini par \u00e9liminer celle-ci, et le benchmark aurait test\u00e9 un appel de m\u00e9thode vide.<\/li>\n\n
  5. Dans ce cas-ci, comme la m\u00e9thode retourne une valeur, on n’a pas besoin de Blackhole<\/code>, retourner un objet suffit.<\/li>\n<\/ol>\n
    Ex\u00e9cuter le microbenchmark<\/h2>\n
    Pour ex\u00e9cuter nos benchmarks, il y a deux solutions : programmatiquement via l’API de JMH, ou via un JAR de benchmark.<\/p>\n
    Pour l\u2019ex\u00e9cuter programmatiquement il faut ajouter un main<\/code> \u00e0 votre classe de benchmark. On peut alors lancer le main depuis son IDE par exemple.<\/p>\n
    \npublic static void main(String[] args) throws RunnerException {\n    Options opt = new OptionsBuilder()\n            .include(ForVsStream.class.getSimpleName())\n            .build();\n\n    new Runner(opt).run();\n}\n<\/pre>\n
    Bien que pratique, cette m\u00e9thode n’est pas la plus recommand\u00e9e, pour passer des param\u00e8tres au benchmark on doit les coder en dur.\nLe lancement depuis un IDE est d\u00e9conseill\u00e9 par le cr\u00e9ateur de JMH : il faut r\u00e9aliser un package Maven avant l’appel de la m\u00e9thode main<\/code> pour initialiser l’infrastructure JMH, et certains IDEs pourraient ne pas le faire.<\/p>\n
    La m\u00e9thode conseill\u00e9e est le lancement via la ligne de commande Maven, apr\u00e8s avoir cr\u00e9\u00e9 l’artefact de benchmark via mvn clean package<\/code>. L’artefact Maven cr\u00e9\u00e9 contient vos benchmarks, ainsi que le code d’infrastructure de JMH. Il sera cr\u00e9\u00e9 dans le r\u00e9pertoire target et aura comme nom benchmarks.jar<\/code>.\nOn pourra ensuite le lancer de mani\u00e8re classique via la ligne de commande java en donnant en param\u00e8tre le nom du benchmark \u00e0 ex\u00e9cuter : java -jar target\/benchmarks.jar ForVsStream<\/code>.<\/p>\n
    Par d\u00e9faut, pour chaque m\u00e9thode de benchmark (et chaque valeur de param\u00e8tre), JMH ex\u00e9cute 5 it\u00e9rations de 10s de pr\u00e9chauffe (warmup) et 5 it\u00e9rations de 10s de mesure.<\/p>\n
    Et voici un exemple de r\u00e9sultats produit :<\/p>\n
    ForVsStream.testForLoop_doNothing                  10  avgt    5      46,715 \u00b1     4,581  ns\/op\nForVsStream.testForLoop_doNothing                1000  avgt    5    4581,216 \u00b1   355,653  ns\/op\nForVsStream.testForLoop_doNothing               10000  avgt    5   45320,910 \u00b1   670,446  ns\/op\nForVsStream.testForLoop_Accumulation               10  avgt    5      12,960 \u00b1     0,809  ns\/op\nForVsStream.testForLoop_Accumulation             1000  avgt    5     749,318 \u00b1    14,473  ns\/op\nForVsStream.testForLoop_Accumulation            10000  avgt    5    6679,846 \u00b1    81,442  ns\/op\n<\/pre>\n
    On a ici 6 colonnes :<\/p>\n
    1. Le nom du microbenchmark (le nom de la m\u00e9thode pr\u00e9fix\u00e9e par le nom de la classe).<\/li>\n\n
    2. La valeur du param\u00e8tre.<\/li>\n\n
    3. Le mode de mesure : ici avgt<\/code> pour average time : le temps moyen d\u2019ex\u00e9cution.<\/li>\n\n
    4. Le nombre d’it\u00e9rations de mesure.<\/li>\n\n
    5. Le r\u00e9sultat : ici en nanoseconde par op\u00e9ration.<\/li>\n\n
    6. L’erreur statistique : si celle-ci est importante par rapport \u00e0 vos r\u00e9sultats (20 – 30%), c’est qu’il y a un soucis.<\/li>\n<\/ol>\n
      On peut modifier la mani\u00e8re dont JMH r\u00e9alise l’ex\u00e9cution du benchmark, et mesure les r\u00e9sultats, de plusieurs mani\u00e8res diff\u00e9rentes : via des param\u00e8tres de ligne de commande, via l’OptionsBuilder<\/code> si vous utilisez un main<\/code>, ou via des annotations \u00e0 placer sur votre classe de Benchmark ou sur une de vos m\u00e9thodes.\nC’est g\u00e9n\u00e9ralement cette option que je pr\u00e9f\u00e8re, car la d\u00e9finition de l’ex\u00e9cution et de la mesure d\u00e9pend g\u00e9n\u00e9ralement de ce que l’on veut mesurer, et n’a pas besoin de changer fr\u00e9quemment (sinon, privil\u00e9giez la ligne de commande).<\/p>\n
      Si vous vous demandez quelles sont les options que l’on peut passer \u00e0 la ligne de commande, il y a une aide int\u00e9gr\u00e9e via java -jar target\/benchmarks.jar -h<\/code>.<\/p>\n
      Voici les options que je passe le plus souvent \u00e0 un benchmark, elles peuvent \u00eatre d\u00e9finies au niveau de la classe ou par m\u00e9thode de benchmark :<\/p>\n
      @BenchmarkMode(Mode.AverageTime)\n@OutputTimeUnit(TimeUnit.NANOSECONDS)\n@Warmup(iterations = 3, time = 3, timeUnit = TimeUnit.SECONDS)\n@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)\n@Fork(1)\npublic class ForVsStream {\n    \/\/ benchmark ...\n}\n<\/pre>\n