.toArray (nouveau MyClass [0]) ou .toArray (nouveau MyClass [myList.size ()])?

En supposant que j'ai une ArrayList

ArrayList<MyClass> myList;

Et je veux appeler toArray, y a-t-il une raison de performance à utiliser

MyClass[] arr = myList.toArray(new MyClass[myList.size()]);

plus de

MyClass[] arr = myList.toArray(new MyClass[0]);

?

Je préfère le deuxième style, car il est moins verbeux, et j'ai supposé que le compilateur s'assurait que le tableau vide ne soit pas vraiment créé, mais je me suis demandé si c'était vrai.

Bien sûr, dans 99% des cas, cela ne fait aucune différence dans un sens ou dans l'autre, mais j'aimerais garder un style cohérent entre mon code normal et mes boucles internes optimisées ...

Contre-intuitivement, la version la plus rapide, sur Hotspot 8, est:

MyClass[] arr = myList.toArray(new MyClass[0]);

J'ai exécuté un micro-benchmark en utilisant jmh, les résultats et le code sont ci-dessous, montrant que la version avec un tableau vide surpasse systématiquement la version avec un tableau prédéfini. Notez que si vous pouvez réutiliser un tableau existant de la taille correcte, le résultat peut être différent.

Résultats de référence (score en microsecondes, plus petit = meilleur):

Benchmark                      (n)  Mode  Samples    Score   Error  Units
c.a.p.SO29378922.preSize         1  avgt       30    0.025 ▒ 0.001  us/op
c.a.p.SO29378922.preSize       100  avgt       30    0.155 ▒ 0.004  us/op
c.a.p.SO29378922.preSize      1000  avgt       30    1.512 ▒ 0.031  us/op
c.a.p.SO29378922.preSize      5000  avgt       30    6.884 ▒ 0.130  us/op
c.a.p.SO29378922.preSize     10000  avgt       30   13.147 ▒ 0.199  us/op
c.a.p.SO29378922.preSize    100000  avgt       30  159.977 ▒ 5.292  us/op
c.a.p.SO29378922.resize          1  avgt       30    0.019 ▒ 0.000  us/op
c.a.p.SO29378922.resize        100  avgt       30    0.133 ▒ 0.003  us/op
c.a.p.SO29378922.resize       1000  avgt       30    1.075 ▒ 0.022  us/op
c.a.p.SO29378922.resize       5000  avgt       30    5.318 ▒ 0.121  us/op
c.a.p.SO29378922.resize      10000  avgt       30   10.652 ▒ 0.227  us/op
c.a.p.SO29378922.resize     100000  avgt       30  139.692 ▒ 8.957  us/op

Pour référence, le code:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
public class SO29378922 {
  @Param({"1", "100", "1000", "5000", "10000", "100000"}) int n;
  private final List<Integer> list = new ArrayList<>();
  @Setup public void populateList() {
    for (int i = 0; i < n; i++) list.add(0);
  }
  @Benchmark public Integer[] preSize() {
    return list.toArray(new Integer[n]);
  }
  @Benchmark public Integer[] resize() {
    return list.toArray(new Integer[0]);
  }
}

Vous pouvez trouver des résultats similaires, une analyse complète et une discussion dans le billet de blog Arrays of Wisdom of the Ancients . Pour résumer: le compilateur JVM et JIT contient plusieurs optimisations qui lui permettent de créer et d'initialiser à moindre coût un nouveau tableau correctement dimensionné, et ces optimisations ne peuvent pas être utilisées si vous créez le tableau vous-même.

À partir de ArrayList dans Java 5 , le tableau sera déjà rempli s'il a la bonne taille (ou est plus grand). par conséquent

MyClass[] arr = myList.toArray(new MyClass[myList.size()]);

va créer un objet tableau, le remplir et le renvoyer à "arr". D'autre part

MyClass[] arr = myList.toArray(new MyClass[0]);

créera deux tableaux. Le second est un tableau de MyClass de longueur 0. Il y a donc une création d'objet pour un objet qui sera immédiatement jeté. Pour autant que le code source le suggère, le compilateur / JIT ne peut pas optimiser celui-ci pour qu'il ne soit pas créé. En outre, l'utilisation de l'objet de longueur nulle entraîne des transtypages dans la méthode toArray ().

Voir la source de ArrayList.toArray ():

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

Utilisez la première méthode pour qu'un seul objet soit créé et évitez les castings (implicites mais néanmoins coûteux).

À partir de l'inspection JetBrains Intellij Idea:

Il existe deux styles pour convertir une collection en tableau: soit en utilisant un tableau pré-dimensionné (comme c.toArray (new String [c.size ()]) ) ou en utilisant un tableau vide (comme c.toArray (new String [ 0]) .

Dans les anciennes versions de Java, l'utilisation d'un tableau prédimensionné était recommandée, car l'appel de réflexion nécessaire pour créer un tableau de taille appropriée était assez lent. Cependant, depuis les dernières mises à jour d'OpenJDK 6, cet appel était intrinsèque, rendant les performances de la version de tableau vide les mêmes et parfois même meilleures, par rapport à la version pré-dimensionnée. Le passage d'un tableau pré-dimensionné est également dangereux pour une collection simultanée ou synchronisée car une course aux données est possible entre la taille et l' appel toArray, ce qui peut entraîner des valeurs nulles supplémentaires à la fin du tableau, si la collection a été réduite simultanément pendant l'opération.

Cette inspection permet de suivre le style uniforme: soit en utilisant un tableau vide (ce qui est recommandé dans Java moderne), soit en utilisant un tableau pré-dimensionné (qui pourrait être plus rapide dans les anciennes versions de Java ou les JVM non basées sur HotSpot).

Les JVM modernes optimisent la construction de la matrice réfléchissante dans ce cas, donc la différence de performances est minime. Nommer la collection deux fois dans un tel code standard n'est pas une bonne idée, alors j'éviterais la première méthode. Un autre avantage du second est qu'il fonctionne avec des collections synchronisées et simultanées. Si vous souhaitez faire une optimisation, réutilisez le tableau vide (les tableaux vides sont immuables et peuvent être partagés), ou utilisez un profileur (!).

toArray vérifie que le tableau passé est de la bonne taille (c'est-à-dire suffisamment grand pour contenir les éléments de votre liste) et si c'est le cas, l'utilise. Par conséquent, si la taille du tableau le fournissait plus petite que nécessaire, un nouveau tableau sera créé par réflexe.

Dans votre cas, un tableau de taille zéro est immuable et peut donc être élevé en toute sécurité à une variable finale statique, ce qui pourrait rendre votre code un peu plus propre, ce qui évite de créer le tableau à chaque appel. Un nouveau tableau sera de toute façon créé à l'intérieur de la méthode, c'est donc une optimisation de la lisibilité.

La version la plus rapide consiste sans doute à transmettre le tableau d'une taille correcte, mais à moins que vous ne puissiez prouver que ce code est un goulot d'étranglement des performances, préférez la lisibilité aux performances d'exécution jusqu'à preuve du contraire.

Le premier cas est plus efficace.

En effet, dans le second cas:

MyClass[] arr = myList.toArray(new MyClass[0]);

le runtime crée en fait un tableau vide (avec une taille nulle), puis à l'intérieur de la méthode toArray crée un autre tableau pour s'adapter aux données réelles. Cette création se fait en utilisant la réflexion en utilisant le code suivant (extrait de jdk1.5.0_10):

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        a = (T[])java.lang.reflect.Array.
    newInstance(a.getClass().getComponentType(), size);
System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

En utilisant le premier formulaire, vous évitez la création d'un deuxième tableau et évitez également le code de réflexion.

Le second est légèrement plus lisible, mais il y a si peu d'amélioration que cela n'en vaut pas la peine. La première méthode est plus rapide, sans inconvénient à l'exécution, c'est donc ce que j'utilise. Mais je l'écris de la deuxième façon, car c'est plus rapide à taper. Ensuite, mon IDE le signale comme un avertissement et propose de le réparer. D'une simple pression sur une touche, il convertit le code du deuxième type au premier.

L'utilisation de 'toArray' avec le tableau de la taille correcte fonctionnera mieux car l'alternative créera d'abord le tableau de taille zéro, puis le tableau de la taille correcte. Cependant, comme vous le dites, la différence sera probablement négligeable.

Notez également que le compilateur javac n'effectue aucune optimisation. De nos jours, toutes les optimisations sont effectuées par les compilateurs JIT / HotSpot lors de l'exécution. Je n'ai connaissance d'aucune optimisation autour de «toArray» dans les machines virtuelles Java.

La réponse à votre question est donc en grande partie une question de style, mais par souci de cohérence, elle doit faire partie de toutes les normes de codage auxquelles vous adhérez (qu'elles soient documentées ou non).

exemple de code pour entier:

Integer[] arr = myList.toArray(new integer[0]);