Почему Collections.sort() намного медленнее, чем Arrays.sort()?

Ответ 1

Итак, существуют два разных метода с совершенно разными алгоритмами:

Arrays.sort(int[]) использует алгоритм быстрой сортировки с двойным шарниром.

Collections.sort(List<T>) вызывает list.sort(null) который в свою очередь вызывает Arrays.sort(T[]). Это использует алгоритм Timsort.

Итак, сравните Arrays.sort(int[]) и Arrays.sort(T[]).

1. T[] - это массив в штучной упаковке, поэтому есть один дополнительный уровень косвенности: для каждого вызова вам необходимо развернуть Integer. Это, безусловно, приводит к накладным расходам. С другой стороны, int[] является примитивным массивом, поэтому все элементы доступны "немедленно".
2. TimSort - это вариация классического алгоритма слияния. Это быстрее, чем mergesort, но он все еще медленнее, чем quicksort, потому что: a) quicksort имеет меньшее количество данных для случайных данных; b) для быстрой сортировки требуется O (log (n)) дополнительное пространство, в то время как TimSort требует O (n) для обеспечения стабильности, что также приводит к накладные расходы.

Ответ 2

Здесь есть два вопроса:

Проблема №1:

Под обложками Collections.sort работает, копируя коллекцию в массив, сортируя массив, а затем копируя массив обратно в коллекцию.

Arrays.sort просто сортирует массив на месте.

Теперь для достаточно большого массива/коллекции стоимость сортировки (O(NlogN)) будет доминировать над стоимостью копирования (O(N)). Для небольшого массива/коллекции копирование становится значительным.

(Такое поведение может зависеть от типа коллекции. Для ArrayList реализация Collections.sort может сортировать массив поддержки без копирования данных. Мне нужно будет проверить исходный код. UPDATE - сортировка по месту, подтвержденная для ArrayList для Java 8 и более поздние версии.)

Проблема № 2:

Вы сравниваете сортировку int[] с сортировкой List<Integer>.

Это яблоки и апельсины. Так как:

1. Сравнение двух значений int с использованием реляционных операторов выполняется быстрее, чем сравнение двух значений Integer с помощью compareTo(Integer).
2. Arrays.sort(int[]) использует другой (более быстрый) алгоритм для того, который используется Arrays.sort(Object[])

Если вы хотите получить более справедливое сравнение, сравните Collections.sort с ArrayList<Integer> с Arrays.sort(Object[]) в Integer[].

Ответ 3

Collection.sort() используется алгоритм сортировки слиянием, а массив Arrays.sort() использует быструю сортировку. Быстрая сортировка имеет серьезные недостатки, когда дело доходит до сортировки слияния, это нестабильно, когда дело доходит до не примитивного. Так что в зависимости от требований мы будем использовать либо Arrays.sort(), либо Collection.sort() для погодных условий для сравнения объектов или примитивов.

Ответ 4

если вы видите Collections.sort() oracle doc здесь, он читает

Эта реализация выгружает указанный список в массив, сортирует массив и выполняет итерацию по списку, сбросив каждый элемент из соответствующей позиции в массиве

что означает, что он выполняет сортировку массива и дополнительную итерацию, это означает, что Collections.sort() работает медленнее, чем массивы.sort

1. выгружает указанный список в массив
2. сортирует массив ~ arrays.sort
3. итерации по списку, сброс каждого элемента из соответствующей позиции в массиве

Ответ 5

Есть одна вещь, которая не упоминалась на этом пути, которая является "преследованием указателя", которая связана с частью "распаковки". Для массива этого небольшого размера, независимо от того, используете ли вы timsort или quicksort, не должно быть существенной разницы (для примитивных массивов с текущими скоростями процессора это, скорее всего, не то, что убивает вашу скорость).

В то время как бокс не происходит за пределами инициализации в вашем примере, большая разница происходит там, где данные считываются.

Поскольку ints являются примитивами, int [] является просто смежной частью памяти, которая содержит сами данные, Integer [] - это непрерывная часть памяти, которая содержит ссылки (то есть указатели) на отдельные объекты данных, и сами объекты Integer могут быть рассеяны по всей памяти.

Таким образом, для операции сортировки по int [] процессор будет извлекать кусок памяти и может напрямую работать с ним. Но для Integer [] CPU должен преследовать указатель для каждого отдельного объекта и получить его из памяти, прежде чем он сможет сравнить его, а затем работать с этим блоком памяти, который является массивом, и переупорядочить это. Это называется "преследованием указателя".

Это не так много, что Integer [] требует больше операций для каждой части данных, например, чтения значения, добавления длины заголовка к базовому адресу и получения значения оттуда (ЦП очень хорошо конструирует эти инструкции и что он скрывает много его воздействия), это латентность памяти, которая убивает вас. Извлечение каждого отдельного объекта Integer из случайной ячейки памяти делает практически всю разницу.

Обычно это не имеет большого значения, так как обычно вы инициализируете довольно небольшое количество Integer [] в узком цикле, и в фоновом режиме не так много, поэтому объекты Integer, вероятно, находятся в непосредственной близости от памяти, могут быть извлечены в кеш и доступ к ним довольно быстро, но для огромных массивов и списков, которые создаются и модифицируются по всему занятому приложению, это может иметь существенное значение и может иметь неожиданные всплески задержки. Вы захотите избежать этого, если вам нужны надежные, низкие задержки. Однако для огромного количества приложений, если сортировка занимает несколько миллисекунд, никто не замечает.

[РЕДАКТИРОВАТЬ]

Как вы просили его в комментарии, здесь код, чтобы показать, что это не о timsort vs quicksort:

import java.util.Arrays;
import java.util.Random;

public class Pointerchasing1 {

    public static void main(String[] args) {

        //use the exact same algorithm implementation (insertionSort), to show that slowness is not caused by timsort vs quicksort.
        //expect that the object-version is slower.

        final int[] direct = new int[1024]; 
        final Integer[] refs = new Integer[direct.length];

        final Random rnd = new Random(0);
        for (int t = 0; t < 1000; ++t) {
            Arrays.setAll(direct, index -> rnd.nextInt());
            Arrays.setAll(refs, index -> direct[index]); // boxing happens here

            //measure direct:
            long t1 = System.nanoTime();
            insertionSortPrimitive(direct);
            long e1 = System.nanoTime()-t1;
            //measure refs:         
            long t2 = System.nanoTime();
            insertionSortObjects(refs);
            long e2 = System.nanoTime()-t2;

            // use results, so compiler can't eliminate the loops
            System.out.println(Arrays.toString(direct));
            System.out.println(Arrays.toString(refs));
            System.out.println("-");            
            System.out.println(e1);
            System.out.println(e2);
            System.out.println("--");           
        }
    }

    private static void insertionSortPrimitive(final int[] arr) {
        int i, key, j;
        for (i = 1; i < arr.length; i++) {
            key = arr[i];
            j = i - 1;
            while (j >= 0 && arr[j] > key) {
                arr[j + 1] = arr[j];
                j = j - 1;
            }
            arr[j + 1] = key;
        }
    }

    private static void insertionSortObjects(final Integer[] arr) {
        int i, key, j;
        for (i = 1; i < arr.length; i++) {
            key = arr[i];
            j = i - 1;
            while (j >= 0 && arr[j] > key) {
                arr[j + 1] = arr[j];
                j = j - 1;
            }
            arr[j + 1] = key;
        }
    }

}

Этот "тест" оставляет вскрытие как возможный виновник.

[EDIT2]

Теперь этот тест должен показать, что "unboxing" не проблема. Unboxing просто добавляет несколько байтов заголовка объектов к адресу (вне порядка исполнения и конвейерная обработка делают эту стоимость почти исчезающей) и получают значение из этого местоположения. В этом тесте я использую два примитивных массива, один для ссылки и один для значения. Поэтому каждый доступ является косвенным. Это очень похоже на unboxing, просто не добавляя лишних байтов для заголовка объекта. Основное различие заключается в том, что "косвенной" версии не нужно преследовать указатель для каждого значения в куче, он может загружать как массивы, так и индекс из массива refs в массив значений.

Если прерывание указателя делает разницу, а не распаковывает, то косвенная версия должна быть быстрее, чем версия объектов, которая делает unboxing.

import java.util.Arrays;
import java.util.Random;

public class Pointerchasing2 {

    public static void main(String[] args) {

        // use indirect access (like unboxing, but just chasing a single array pointer) vs. Integer objects (chasing every object pointer).
        // expect that the object-version is still slower.

        final int[] values = new int[1024];
        final int[] refs = new int[1024];
        final Integer[] objects = new Integer[values.length];

        final Random rnd = new Random(0);
        for (int t = 0; t < 1000; ++t) {
            Arrays.setAll(values, index -> rnd.nextInt());
            Arrays.setAll(refs, index -> index);
            Arrays.setAll(objects, index -> values[index]); // boxing happens here

            // measure indirect:
            long t1 = System.nanoTime();
            insertionSortPrimitiveIndirect(refs, values);
            long e1 = System.nanoTime() - t1;
            // measure objects:
            long t2 = System.nanoTime();
            insertionSortObjects(objects);
            long e2 = System.nanoTime() - t2;

            // use results, so compiler can't eliminate the loops
            System.out.println(Arrays.toString(indirectResult(refs, values)));
            System.out.println(Arrays.toString(objects));
            System.out.println("-");
            System.out.println(e1);
            System.out.println(e2);
            System.out.println("--");
        }
    }

    private static void insertionSortPrimitiveIndirect(final int[] refs, int[] values) {
        int i, keyIndex, j;
        for (i = 1; i < refs.length; i++) {
            keyIndex = refs[i];
            j = i - 1;
            while (j >= 0 && values[refs[j]] > values[keyIndex]) {
                refs[j + 1] = refs[j];
                j = j - 1;
            }
            refs[j + 1] = keyIndex;
        }
    }

    private static void insertionSortObjects(final Integer[] arr) {
        int i, key, j;
        for (i = 1; i < arr.length; i++) {
            key = arr[i];
            j = i - 1;
            while (j >= 0 && arr[j] > key) {
                arr[j + 1] = arr[j];
                j = j - 1;
            }
            arr[j + 1] = key;
        }
    }

    private static int[] indirectResult(final int[] refs, int[] values) {
        final int[] result = new int[1024];
        Arrays.setAll(result, index -> values[refs[index]]);
        return result;
    }

}

Результат: В обоих этих тестах "примитивные" и "косвенные" версии быстрее, чем доступ к объектам в куче. Следует ожидать, что unboxing не убивает скорость, а латентность памяти через погоню за указателем.

Смотрите также это видео по проекту Valhalla: ("Типы значений и общая специализация в JVM обещают дать нам лучший JIT-код, локальность данных и удалить тиранию преследователя". Https://vimeo.com/289667280