web-dev-qa-db-fra.com

Performances du JDK 11 vs JDK 13

[~ # ~] mise à jour [~ # ~]

Tout au long des commentaires, il s'est avéré que l'approche de référence que j'avais adoptée était incorrecte et que les résultats étaient donc trompeurs. Après avoir corrigé mon approche (comme dans la réponse acceptée), les résultats sont comme on pouvait s'y attendre - les performances du JDK 13 sont tout aussi bonnes qu'avec le JDK 11. Voir la réponse pour plus de détails.

Question d'origine

Je faisais des tests de performances sur HashSet sous Windows 10, en utilisant le code de test suivant pour JMH:

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@Fork(value = 1, warmups = 1)
public void init() {
    HashSet<String> s = new HashSet<>();
    for (int i = 0; i < 1000000; i++) {
        s.add(Math.random() + "");
    }
    s.size();
}

Je l'ai compilé et exécuté sous différentes versions de JDK et voici les résultats que j'ai obtenus:

enter image description here

Je l'ai testé avec différentes tailles de tas (donc 3 couleurs différentes pour chaque JDK). JDK 14 est bien sûr un instantané de pré-version d'aujourd'hui - juste pour voir ZGC fonctionner sous Windows.

Je me demande - que s'est-il passé après le JDK 11? (notez que pour JDK 12, il commence déjà à grandir, même s'il n'est pas présent sur le graphique ci-dessus)

javagarbage-collectionjvmjava-11java-13
6
Googie

Merci à tous pour les suggestions dans les commentaires.

La réponse était très probablement Math.random() ou HashSet, ou manquant Blackhole::consume ou une combinaison de tous. J'ai changé le test pour faire simplement i + "aaaaaaaaa" et remplacé HashSet par ArrayList pré-initialisé avec la taille appropriée pour s'adapter à toutes les valeurs à remplir. J'ai également ajouté Blackhole::consume à la fin pour exclure les optimisations JIT indésirables.

Après tout cela, le timing passe progressivement du JDK 8 à 11, puis reste à peu près le même dans le JDK 11-13. Dans JDK 14, il augmente légèrement, mais bon - il n'est pas encore sorti.

1
Googie