.toArray (nueva MyClass [0]) o .toArray (nueva MyClass [myList.size ()])?

Suponiendo que tengo una ArrayList

ArrayList<MyClass> myList;

Y quiero llamar a Array, ¿hay alguna razón de rendimiento para usar

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

encima

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

?

Prefiero el segundo estilo, ya que es menos detallado, y asumí que el compilador se asegurará de que la matriz vacía no se cree realmente, pero me he estado preguntando si eso es cierto.

Por supuesto, en el 99% de los casos no hace la diferencia de una forma u otra, pero me gustaría mantener un estilo consistente entre mi código normal y mis bucles internos optimizados ...

Contraintuitivamente, la versión más rápida, en Hotspot 8, es:

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

He ejecutado un micro benchmark usando jmh, los resultados y el código están a continuación, lo que muestra que la versión con una matriz vacía supera constantemente la versión con una matriz preestablecida. Tenga en cuenta que si puede reutilizar una matriz existente del tamaño correcto, el resultado puede ser diferente.

Resultados de referencia (puntuación en microsegundos, menor = mejor):

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

Como referencia, el código:

@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]);
  }
}

Puede encontrar resultados similares, análisis completo y discusión en la publicación de blog Arrays of Wisdom of the Ancients . Para resumir: el compilador JVM y JIT contiene varias optimizaciones que le permiten crear e inicializar de forma económica una nueva matriz de tamaño correcto, y esas optimizaciones no se pueden usar si crea la matriz usted mismo.

A partir de ArrayList en Java 5 , la matriz ya se completará si tiene el tamaño correcto (o es más grande). Por consiguiente

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

creará un objeto de matriz, lo llenará y lo devolverá a "arr". Por otra parte

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

creará dos matrices. El segundo es una matriz de MyClass con longitud 0. Por lo tanto, hay una creación de objeto para un objeto que se desechará de inmediato. En la medida en que el código fuente sugiere que el compilador / JIT no puede optimizar este, por lo que no se crea. Además, el uso del objeto de longitud cero produce fundición (es) dentro del método toArray ().

Vea la fuente 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;
}

Use el primer método para que solo se cree un objeto y evite los moldes (implícitos pero caros).

De la inspección de JetBrains Intellij Idea:

Hay dos estilos para convertir una colección en una matriz: ya sea usando una matriz previamente dimensionada (como c.toArray (new String [c.size ()]) ) o usando una matriz vacía (como c.toArray (new String [ 0]) .

En versiones anteriores de Java se recomendaba el uso de una matriz de tamaño predeterminado, ya que la llamada de reflexión necesaria para crear una matriz del tamaño adecuado era bastante lenta. Sin embargo, desde las últimas actualizaciones de OpenJDK 6, esta llamada fue intrinsificada, lo que hace que el rendimiento de la versión de matriz vacía sea el mismo y, a veces, incluso mejor, en comparación con la versión de tamaño predeterminado. Además, pasar una matriz previamente dimensionada es peligroso para una colección simultánea o sincronizada, ya que es posible una carrera de datos entre el tamaño y la llamada a la matriz que puede generar nulos adicionales al final de la matriz, si la colección se redujo simultáneamente durante la operación.

Esta inspección permite seguir el estilo uniforme: ya sea usando una matriz vacía (que se recomienda en Java moderno) o usando una matriz de tamaño predeterminado (que podría ser más rápida en versiones Java anteriores o JVM no basadas en HotSpot).

Las JVM modernas optimizan la construcción de matriz reflectante en este caso, por lo que la diferencia de rendimiento es pequeña. Nombrar la colección dos veces en ese código repetitivo no es una gran idea, por lo que evitaría el primer método. Otra ventaja de la segunda es que funciona con colecciones sincronizadas y concurrentes. Si desea optimizar, reutilice la matriz vacía (las matrices vacías son inmutables y se pueden compartir), o use un generador de perfiles (!).

toArray verifica que la matriz pasada sea del tamaño correcto (es decir, lo suficientemente grande como para ajustarse a los elementos de su lista) y, de ser así, la usa. Por consiguiente, si el tamaño de la matriz lo proporciona más pequeño de lo requerido, se creará una nueva matriz por reflejo.

En su caso, una matriz de tamaño cero es inmutable, por lo que podría elevarse con seguridad a una variable final estática, lo que podría hacer que su código sea un poco más limpio, lo que evita crear la matriz en cada invocación. De todos modos, se creará una nueva matriz dentro del método, por lo que es una optimización de legibilidad.

Podría decirse que la versión más rápida es pasar la matriz de un tamaño correcto, pero a menos que pueda probar que este código es un cuello de botella de rendimiento, prefiera la legibilidad al rendimiento en tiempo de ejecución hasta que se demuestre lo contrario.

El primer caso es más eficiente.

Eso es porque en el segundo caso:

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

el tiempo de ejecución realmente crea una matriz vacía (con tamaño cero) y luego dentro del método toArray crea otra matriz para adaptarse a los datos reales. Esta creación se realiza utilizando la reflexión utilizando el siguiente código (tomado 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;
}

Al usar la primera forma, evita la creación de una segunda matriz y también evita el código de reflexión.

El segundo es marginalmente más legible, pero hay tan poca mejora que no vale la pena. El primer método es más rápido, sin desventajas en tiempo de ejecución, así que eso es lo que uso. Pero lo escribo de la segunda manera, porque es más rápido escribir. Entonces mi IDE lo marca como una advertencia y ofrece arreglarlo. Con una sola pulsación de tecla, convierte el código del segundo tipo al primero.

El uso de 'toArray' con la matriz del tamaño correcto funcionará mejor ya que la alternativa creará primero la matriz de tamaño cero y luego la matriz del tamaño correcto. Sin embargo, como usted dice, es probable que la diferencia sea insignificante.

Además, tenga en cuenta que el compilador javac no realiza ninguna optimización. En la actualidad, los compiladores JIT / HotSpot realizan todas las optimizaciones en tiempo de ejecución. No conozco ninguna optimización en torno a 'toArray' en ninguna JVM.

La respuesta a su pregunta, entonces, es en gran medida una cuestión de estilo, pero por razones de coherencia debe formar parte de cualquier estándar de codificación al que se adhiera (ya sea documentado o no).

código de muestra para entero:

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