Tutoriel sur l'injection de données avec JMH, l'outil de benchmark de la JDK

Prenons le benchmark suivant, qui mesure le coût de l'ajout d'un jour (rolling) à une date donnée :

@Benchmark
public Calendar benchmark_roll_new_Date() {
   // create a calendar set to "now"
   Calendar c = Calendar.getInstance();
   // roll "now" of 1 day
   c.roll(Calendar.DAY_OF_YEAR, 1);
   return c;
}

Ce benchmark est-il correct ? En un sens oui, il mesure le temps d'exécution de ce morceau de code. Néanmoins, ce n'est pas ce que l'on cherchait à mesurer : certes, on mesure ici le temps de rolling d'une date, mais on y ajoute également le temps de construction d'une instance de Calendar, ainsi que (et surtout) le temps d'un appel OS, pour récupérer la date système ! Cette opération système n'est pas gratuite, et peut même être significativement plus longue que le code que l'on souhaite réellement benchmarker, faussant alors complètement notre benchmark !

Heureusement, JMH prend en charge l'injection de données : il suffit de déclarer un type contenant un « état » (décoré d'un @State) à injecter au benchmark :

@State(Scope.Benchmark)
public static class DateContainer {
   // an object DateContainer will be instanciatedd
   // out of benchmark time by JMH Runner
 
   // get system date (long time operation)
   Calendar now = Calendar.getInstance();
 
   // get a copy of "now" calendar (quick operation)
   Calendar getCalendarSetToNow() {
      return (Calendar) now.clone();
   }
}
 
@Benchmark
public Calendar benchmark_roll_date_in_argument(DateContainer d) {
   // get calendar for "now", created before benchmark
   Calendar c =  d.getCalendarSetToNow();
   // roll date
   c.roll(Calendar.DAY_OF_YEAR, 1);
   return c;
}

De cette manière, le Runner JMH instanciera hors benchmark un objet DateContainer et le passera en argument à la méthode benchmark_roll_date_in_argument(). On peut ainsi se rendre compte de l'overhead dû à l'appel système pour récupérer la date, en comparant les résultats des deux benchmarks ci-dessus :

Près de 60 % du temps (158 sur 252 ns) est passé dans l'appel système ! Celui-ci est donc loin d'être anodin.

Vous remarquerez par ailleurs que le @State porte un Scope qui définit la visibilité de l'objet. En effet, que se passe-t-il lorsque le benchmark est réalisé en multithreadé ?

Le Scope répond à cette question :

• en Scope.Banchmark, l'objet sera partagé parmi tous les threads gérés par JMH ;
• en Scope.Thread, chaque thread aura son propre objet non partagé ;
• en Scope.Group, l'objet sera partagé, mais au sein d'un groupe de threads seulement.

À la manière de JUnit, il existe dans JMH des « fixtures » pour initialiser et nettoyer ce contexte d'exécution avant et après le benchmark. Ainsi nous pouvons dire à JMH comment initialiser/détruire nos objets @State, en implémentant des méthodes annotées par un @Setup et @TearDown. Par ailleurs, on précisera un Level sur ces annotations, qui définira à quel moment elles doivent être appelées par le Runner :

• Level.Trial, déclenchera une exécution au début/à la fin du benchmark (i.e. la séquence d'itérations) ;
• Level.Iteration, déclenchera une exécution avant/après chaque itération ;
• Level.Invocation, déclenchera une exécution avant/après chaque invocation. (Attention, comme indiqué dans la javadoc, ce level peut aboutir à des résultats totalement biaisés sur des opérations < 1 ms ! Pour utilisateur averti.)

Dans l'exemple qui suit, on souhaite benchmarker le tri d'un tableau ; on utilisera alors les « fixtures » pour :

1. Créer un tableau d'entiers non trié au début du benchmark ;
2. Recopier ce tableau non trié avant chaque invocation, afin de le trier (on triera ainsi toujours les mêmes données à chaque invocation).

@State(Scope.Benchmark)
public static class ArrayContainer {
   // initial unsorted array
   int [] suffledArray = new int[10000000];
   // system date copy
   int [] arrayToSort = new int[10000000];
 
   @Setup(Level.Trial)
   public void initArray() {
      // create a shuffled array of int
      // ...
   }
 
   @Setup(Level.Invocation)
   public void makeArrayCopy() {
      // copy shuffled array to reinit the array to sort
      arrayToSort = suffledArray.clone();
   }
 
   int[] getArrayToSort() {
      return arrayToSort;
   }
}
 
@Benchmark
public int[] benchmark_array_sort(ArrayContainer d) {
   // sort copy of shuffled array
   Arrays.sort(d.getArrayToSort());
   // array is now sorted !
   return d.getArrayToSort();
}

Le niveau Level.invocation étant susceptible de fausser le benchmak sur des invocations courtes (< 1 ms), on s'assurera que le coût des « fixtures » est négligeable face au tri, en benchmarkant un code « vide » :

@Benchmark
public int[] baseline(ArrayContainer d) {
   // empty benchmark check the Level.Invocation setup fixture
   // does not impact significativly the measures on benchmark_array_sort()
   return null;
}

Les résultats obtenus nous confirmeront que l'appel des « fixtures » est bien indolore (0.001 << 10.222 ms) pour notre benchmark du tri :

Prenons le code du benchmark suivant :

@State(Scope.Benchmark)
public static class ArrayContainer {
   @Param({ "10000", "100000", "1000000", "10000000", "100000000"})
   int arraySize;
 
   // initial unsorted array
   int [] suffledArray;
 
   // system date copy
   int [] arrayToSort;
 
   @Setup(Level.Trial)
   public void initArray() {
      // create a shuffled array of int
      suffledArray = new int[arraySize];
      // ...
   }
   // ...
}

Nous pouvons grâce à cela, jouer sur la taille du tableau à trier, et montrer ainsi la corrélation taille du tableau/temps de traitement :

Ces résultats nous montrent :

1. Que les mesures réalisées dans le contexte de ce benchmark ne sont pas biaisées par la fixture de niveau Level.invocation : en effet, les temps « baseline » (< 3 µs) sont très inférieurs aux temps des benchmark_array_sot() (> 486 µs) ;
2. Que ce tri a une complexité de type n.log(n)), comme le montre la courbe ci-dessous (échelle logarithmique) :

Nous allons à présent comparer le tri « parallélisé » disponible depuis le jdk 8 via l'API stream avec le tri « classique », à travers ce benchmark :

@State(Scope.Benchmark)
public static class ArrayContainer {
   @Param({ "10", "15", "20", "25", "30", "40", "60", "80", "100", "200", "400", "800", "1000", "10000", "100000", "1000000", "10000000" })
   int arraySize;
   // …
}
 
@Benchmark
public int[] benchmark_array_sort(ArrayContainer d) {
   // parallel sort
   return Arrays.stream(d.getArrayToSort())
                .parallel()
                .sorted()
                .toArray();
}
 
@Benchmark
public int[] baseline(ArrayContainer d) {
   // sort
   return Arrays.stream(d.getArrayToSort())
                .sorted()
                .toArray();
}

Bien évidemment, les processeurs actuels tout comme Rodrigue, ont beaucoup de cœurs, on s'attend donc à en bénéficier dans le tri parallèle ! Néanmoins, les résultats que nous obtenons sont plus subtils que cela (échelle logarithmique) :

Nous pouvons constater que le tri parallèle est effectivement plus rapide (jusqu'à 2 fois), mais seulement à partir d'une taille critique (quelques milliers d'entiers) : en dessous de cette taille, le tri parallèle est jusqu'à 10 fois plus lent, le coup de la parallélisation étant supérieur au gain qu'elle apporte !