.toArray (новый MyClass [0]) или .toArray (новый MyClass [myList.size ()])?

Предполагая, что у меня есть ArrayList

ArrayList<MyClass> myList;

И я хочу вызвать toArray, есть ли причина для использования производительности

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

над

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

?

Я предпочитаю второй стиль, так как он менее многословен, и я предполагал, что компилятор позаботится о том, чтобы пустой массив на самом деле не создавался, но мне было интересно, правда ли это.

Конечно, в 99% случаев это не имеет значения, так или иначе, но я хотел бы сохранить согласованный стиль между моим нормальным кодом и оптимизированными внутренними циклами ...

Как ни странно, самая быстрая версия на Hotspot 8:

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

Я запустил микро-бенчмарк, используя jmh, результаты и код приведены ниже, показывая, что версия с пустым массивом стабильно превосходит версию с предварительно определенным массивом. Обратите внимание, что если вы можете повторно использовать существующий массив правильного размера, результат может быть другим.

Результаты тестов (оценка в микросекундах, меньше = лучше):

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

Для справки, код:

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

Вы можете найти похожие результаты, полный анализ и обсуждение в блоге Arrays of Wisdom of the Ancients . Подводя итог: компилятор JVM и JIT содержит несколько оптимизаций, которые позволяют ему дешево создавать и инициализировать новый массив правильного размера, и эти оптимизации нельзя использовать, если вы создаете массив самостоятельно.

Что касается ArrayList в Java 5 , массив будет заполнен уже, если он имеет правильный размер (или больше). следовательно

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

создаст один объект массива, заполнит его и вернет его в «arr». С другой стороны

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

создаст два массива. Второй - это массив MyClass с длиной 0. Таким образом, существует объект для объекта, который будет немедленно отброшен. Поскольку исходный код предполагает, что компилятор / JIT не может оптимизировать этот, чтобы он не был создан. Кроме того, использование объекта нулевой длины приводит к приведению типов в методе toArray ().

Смотрите источник 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;
}

Используйте первый метод, чтобы создать только один объект, и избегайте (неявных, но, тем не менее, дорогих) приведений.

Из JetBrains Intellij Идея осмотра:

Существует два стиля для преобразования коллекции в массив: либо с использованием предварительно заданного размера (например, c.toArray (new String [c.size ()]) ), либо с использованием пустого массива (например, c.toArray (new String [ 0]) .

В более старых версиях Java было рекомендовано использование массива с предварительно заданным размером, поскольку вызов отражения, необходимый для создания массива правильного размера, был довольно медленным. Однако после поздних обновлений OpenJDK 6 этот вызов был встроен, что сделало производительность пустой версии массива такой же, а иногда даже лучше, по сравнению с версией предварительного размера. Также передача массива предварительно заданного размера опасна для одновременной или синхронизированной коллекции, так как возможна гонка данных между вызовом size и toArray, что может привести к появлению дополнительных нулей в конце массива, если коллекция одновременно сокращалась во время операции.

Эта проверка позволяет следовать единому стилю: либо с использованием пустого массива (что рекомендуется в современной Java), либо с использованием массива предварительно заданного размера (который может быть быстрее в более старых версиях Java или JVM не на основе HotSpot).

Современные JVM оптимизируют конструкцию отражательного массива в этом случае, поэтому разница в производительности незначительна. Называть коллекцию дважды в таком стандартном коде не очень хорошая идея, поэтому я бы избегал первого метода. Еще одним преимуществом второго является то, что он работает с синхронизированными и одновременными коллекциями. Если вы хотите провести оптимизацию, повторно используйте пустой массив (пустые массивы являются неизменяемыми и могут использоваться совместно) или используйте профилировщик (!).

toArray проверяет, что переданный массив имеет правильный размер (то есть достаточно большой, чтобы вместить элементы из вашего списка) и, если это так, использует это. Следовательно, если размер массива будет меньше требуемого, будет создан рефлексивно новый массив.

В вашем случае массив нулевого размера является неизменным, поэтому его можно безопасно преобразовать в статическую конечную переменную, что может сделать ваш код немного чище, что позволяет избежать создания массива при каждом вызове. В любом случае внутри метода будет создан новый массив, так что это удобочитаемость.

Возможно, более быстрая версия - передать массив правильного размера, но если вы не можете доказать, что этот код является узким местом в производительности, предпочтите удобочитаемость производительности во время выполнения, пока не доказано обратное.

Первый случай более эффективен.

Это потому, что во втором случае:

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

среда выполнения фактически создает пустой массив (с нулевым размером), а затем внутри метода toArray создает другой массив для соответствия фактическим данным. Это создание выполняется с использованием отражения с использованием следующего кода (взятого из 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;
}

Используя первую форму, вы избегаете создания второго массива, а также избегаете кода отражения.

Второй вариант немного читабелен, но улучшений так мало, что оно того не стоит. Первый способ быстрее, без недостатков во время выполнения, поэтому я использую его. Но я пишу это вторым способом, потому что это быстрее печатать. Тогда моя IDE помечает это как предупреждение и предлагает исправить это. Одним нажатием клавиши он преобразует код из второго типа в первый.

Использование 'toArray' с массивом правильного размера будет работать лучше, так как альтернатива создаст сначала массив нулевого размера, а затем массив правильного размера. Однако, как вы говорите, разница, вероятно, будет незначительной.

Также обратите внимание, что компилятор javac не выполняет никакой оптимизации. В настоящее время все оптимизации выполняются компиляторами JIT / HotSpot во время выполнения. Я не знаю каких-либо оптимизаций вокруг 'toArray' в каких-либо JVM.

Таким образом, ответ на ваш вопрос в значительной степени зависит от стиля, но ради согласованности должен являться частью любых стандартов кодирования, которых вы придерживаетесь (документированных или иных).

Пример кода для целого числа:

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