I tried to do a test, regarding Collection.sort() and Arrays.sort(). In the test, I created an array of ints of length 1e5 100 times, which contained random numbers from 1 to 1e5. I also created a list of type Integer, which contained the same values at the same positions as that of the array. Then I sorted the array using Arrays.sort() and the list using Collections.sort().

UPDATE: As @Holger pointed out, my code had a bug. The corrected code is now:

import java.util.* ;

class TestClass {
        double ratSum = 0 ;
        int[] A = new int[(int)1e5] ;
        List<Integer> L = new ArrayList<Integer>() ;
            int no = (int)(Math.random()*(int)1e5) ;
            A[i] = no ;
            L.add(A[i]) ;

        long startTime = System.nanoTime() ;
        Arrays.sort(A) ;
        long endTime = System.nanoTime() ;
        Collections.sort(L) ;
        long endTime2 = System.nanoTime() ;
        long t1 = (endTime-startTime), t2 = (endTime2-endTime) ;
        ratSum+=(double)t2/t1 ;
        System.out.println("Arrays.sort took :"+t1+" Collections.sort took :"+t2+" ratio :"+((double)t2/t1)) ;
    System.out.println("Average ratio :"+(ratSum/100)) ;

And the output is:

Arrays.sort took :24106021 Collections.sort took :92353602 ratio :3.8311425182944956
Arrays.sort took :8672831 Collections.sort took :50936497 ratio :5.873110752417521
Arrays.sort took :8561227 Collections.sort took :25611480 ratio :2.991566512603859
Arrays.sort took :7123928 Collections.sort took :17368785 ratio :2.4380910362934607
Arrays.sort took :6280488 Collections.sort took :16929218 ratio :2.6955258890710403
Arrays.sort took :6248227 Collections.sort took :16844915 ratio :2.695951187432851
Arrays.sort took :6220942 Collections.sort took :16979669 ratio :2.7294369566538315
Arrays.sort took :6213841 Collections.sort took :17439817 ratio :2.8066081832476883
Arrays.sort took :6286385 Collections.sort took :19963612 ratio :3.175690321225951
Arrays.sort took :6209668 Collections.sort took :17008307 ratio :2.7390042430609816
Arrays.sort took :6286623 Collections.sort took :17007163 ratio :2.705293923303497
Arrays.sort took :6256505 Collections.sort took :16911950 ratio :2.703098614961548
Arrays.sort took :6225031 Collections.sort took :16914494 ratio :2.7171742598550916
Arrays.sort took :6233918 Collections.sort took :17005995 ratio :2.72797861633727
Arrays.sort took :6210554 Collections.sort took :17606028 ratio :2.834856278522013
Arrays.sort took :6239384 Collections.sort took :20342378 ratio :3.260318326296314
Arrays.sort took :6207695 Collections.sort took :16519089 ratio :2.6610664666997974
Arrays.sort took :6227147 Collections.sort took :16605884 ratio :2.666692146499834
Arrays.sort took :6225187 Collections.sort took :16687597 ratio :2.680657946500242
Arrays.sort took :6152338 Collections.sort took :16475373 ratio :2.6779043999208105
Arrays.sort took :6184746 Collections.sort took :16511024 ratio :2.6696365541931715
Arrays.sort took :6130221 Collections.sort took :16578032 ratio :2.7043122915144493
Arrays.sort took :6271927 Collections.sort took :16507152 ratio :2.631910734930429
Arrays.sort took :6232482 Collections.sort took :16562166 ratio :2.657394919070765
Arrays.sort took :6218992 Collections.sort took :16552468 ratio :2.661599821964717
Arrays.sort took :6230427 Collections.sort took :21954967 ratio :3.52383022865046
Arrays.sort took :8204666 Collections.sort took :16607560 ratio :2.024160398485447
Arrays.sort took :6272619 Collections.sort took :22061291 ratio :3.5170781136236715
Arrays.sort took :8618253 Collections.sort took :19979549 ratio :2.3182829513127543
Arrays.sort took :6198538 Collections.sort took :17002645 ratio :2.743008915973412
Arrays.sort took :6265018 Collections.sort took :17079646 ratio :2.7261926462142645
Arrays.sort took :6302335 Collections.sort took :17040082 ratio :2.7037728080148073
Arrays.sort took :6293948 Collections.sort took :17133482 ratio :2.722215372608735
Arrays.sort took :6272364 Collections.sort took :17099717 ratio :2.7261997231028046
Arrays.sort took :6219540 Collections.sort took :17026849 ratio :2.737637992520347
Arrays.sort took :6231000 Collections.sort took :17149439 ratio :2.7522771625742255
Arrays.sort took :6309215 Collections.sort took :17118779 ratio :2.713297771592821
Arrays.sort took :6200511 Collections.sort took :17123517 ratio :2.7616299688848227
Arrays.sort took :6263169 Collections.sort took :16995685 ratio :2.7135919532109063
Arrays.sort took :6212243 Collections.sort took :17101848 ratio :2.7529264389689843
Arrays.sort took :6247580 Collections.sort took :17089850 ratio :2.735435160494143
Arrays.sort took :6283626 Collections.sort took :17088109 ratio :2.7194662763188004
Arrays.sort took :6312678 Collections.sort took :17055856 ratio :2.7018415955954036
Arrays.sort took :6222695 Collections.sort took :17071263 ratio :2.7433873908330715
Arrays.sort took :6300990 Collections.sort took :17016171 ratio :2.7005551508572463
Arrays.sort took :6262923 Collections.sort took :17084477 ratio :2.727875945465081
Arrays.sort took :6256482 Collections.sort took :17062232 ratio :2.7271287602202006
Arrays.sort took :6259643 Collections.sort took :17036036 ratio :2.721566709155778
Arrays.sort took :6248649 Collections.sort took :16944960 ratio :2.711779778316881
Arrays.sort took :6264515 Collections.sort took :16986876 ratio :2.7116027338109974
Arrays.sort took :6241864 Collections.sort took :17367903 ratio :2.782486609769133
Arrays.sort took :6297429 Collections.sort took :17080086 ratio :2.7122316107097038
Arrays.sort took :6184084 Collections.sort took :17584862 ratio :2.843567778186713
Arrays.sort took :6315776 Collections.sort took :22279278 ratio :3.5275598754610678
Arrays.sort took :6253047 Collections.sort took :17091694 ratio :2.7333384828228544
Arrays.sort took :6291188 Collections.sort took :17147694 ratio :2.725668665441249
Arrays.sort took :6327348 Collections.sort took :17034007 ratio :2.6921242517402235
Arrays.sort took :6284904 Collections.sort took :17049315 ratio :2.712740719667317
Arrays.sort took :6190436 Collections.sort took :17143853 ratio :2.7694096183209065
Arrays.sort took :6301712 Collections.sort took :17070237 ratio :2.7088253160411013
Arrays.sort took :6208193 Collections.sort took :17060372 ratio :2.74804149935416
Arrays.sort took :6247700 Collections.sort took :16961962 ratio :2.7149130079869392
Arrays.sort took :6344996 Collections.sort took :17084627 ratio :2.6926143058246215
Arrays.sort took :6214232 Collections.sort took :17150324 ratio :2.759846108095095
Arrays.sort took :6224359 Collections.sort took :17081254 ratio :2.744259127727048
Arrays.sort took :6256722 Collections.sort took :17005451 ratio :2.7179489515436357
Arrays.sort took :6286439 Collections.sort took :17061112 ratio :2.713954911516679
Arrays.sort took :6250634 Collections.sort took :17091313 ratio :2.7343327092899696
Arrays.sort took :6252900 Collections.sort took :17041659 ratio :2.7254008540037424
Arrays.sort took :6222192 Collections.sort took :17125062 ratio :2.75225547524088
Arrays.sort took :6227037 Collections.sort took :17013314 ratio :2.7321684454420296
Arrays.sort took :6223609 Collections.sort took :17086112 ratio :2.745370411283871
Arrays.sort took :6280777 Collections.sort took :17091821 ratio :2.7212908530266238
Arrays.sort took :6254551 Collections.sort took :17148242 ratio :2.741722307484582
Arrays.sort took :6250927 Collections.sort took :17053331 ratio :2.7281283240069834
Arrays.sort took :6270616 Collections.sort took :17067948 ratio :2.721893351466586
Arrays.sort took :6223093 Collections.sort took :17034584 ratio :2.737317922132933
Arrays.sort took :6286002 Collections.sort took :17128280 ratio :2.7248289135129133
Arrays.sort took :6239485 Collections.sort took :17032062 ratio :2.7297224049741287
Arrays.sort took :6191290 Collections.sort took :17017219 ratio :2.748574045150526
Arrays.sort took :6134110 Collections.sort took :17069485 ratio :2.782715830006309
Arrays.sort took :6207363 Collections.sort took :17052862 ratio :2.747199092432648
Arrays.sort took :6238702 Collections.sort took :17056945 ratio :2.734053493819708
Arrays.sort took :6185356 Collections.sort took :17006088 ratio :2.749411351585907
Arrays.sort took :6309226 Collections.sort took :17056503 ratio :2.703422416632405
Arrays.sort took :6256706 Collections.sort took :17082903 ratio :2.7303349398229675
Arrays.sort took :6194988 Collections.sort took :17069426 ratio :2.7553606237816766
Arrays.sort took :6184266 Collections.sort took :17054641 ratio :2.757746998592881
Arrays.sort took :6271022 Collections.sort took :17086036 ratio :2.724601508334686
Arrays.sort took :6246482 Collections.sort took :17077804 ratio :2.733987546910405
Arrays.sort took :6194985 Collections.sort took :17119911 ratio :2.763511291794895
Arrays.sort took :6319199 Collections.sort took :17444587 ratio :2.760569337980969
Arrays.sort took :6262827 Collections.sort took :17065589 ratio :2.7249018693954024
Arrays.sort took :6301245 Collections.sort took :17195611 ratio :2.728922776371971
Arrays.sort took :6214333 Collections.sort took :17024645 ratio :2.739577199998777
Arrays.sort took :6213116 Collections.sort took :17382033 ratio :2.7976353572024086
Arrays.sort took :6286394 Collections.sort took :17124874 ratio :2.7241171965995132
Arrays.sort took :6166308 Collections.sort took :16998293 ratio :2.756640278104824
Arrays.sort took :6247395 Collections.sort took :16957056 ratio :2.7142602636779007
Arrays.sort took :6245054 Collections.sort took :16994147 ratio :2.72121698227109
Average ratio :2.792654880602193

Moreover, I ran the code locally, 1000 times (instead of 100) and the average ratio was: :3.0616 So, the ratio is still significant and thus worthy of discussion.

Question: Why does Collections.sort() take approximately 3 times of the time taken by Arrays.sort() to sort the same values? Is it because now we're not comparing primitives? Why would that take more time?

  • 2
    Collections.sort() has overheads, because Integer is class( additional operations are there), where as Arrays.sort() , it has reduced operation as the elemetns are int primitive . – The Scientific Method Oct 9 '18 at 5:53
  • @TheScientificMethod Overheads are inferable from the extra running time. But exactly which ones do this? What exactly slows Collections.sort() down? – Mooncrater Oct 9 '18 at 6:04
  • 2
    Java has primitive types as wrapper types have higher overheads in terms of memory and cpu. – Peter Lawrey Oct 9 '18 at 7:37
  • 1
    As Holger pointed out, int no = (int)Math.random()*(int)1e5 ; will always set no to 0. This is because Math.random() returns a float between 0 and 1, so it will always be truncated to 0 when cast to an int. – Kevin Oct 9 '18 at 15:42

So, there are two different methods with totally different algorithms here:

Arrays.sort(int[]) uses a dual-pivot quicksort algorithm.

Collections.sort(List<T>) calls list.sort(null) which in turn calls Arrays.sort(T[]). This uses a Timsort algorithm.

So, let's compare Arrays.sort(int[]) and Arrays.sort(T[]).

  1. T[] is a boxed array so there is one extra level of indirection: for each call, you have to unwrap Integer. This certainly leads to an overhead. On the other hand, int[] is a primitive array so all elements are available "immediately".
  2. TimSort is a variation of a classic mergesort algorithm. It is faster than mergesort but it still slower than quicksort because
    • quicksort has fewer data movements on random data
    • quicksort requires O(log(n)) extra space while TimSort requires O(n) to provide stability which also leads to an overhead.
  • 17
    That eventually makes so much sense. Stability in the case of primitives doesn't matter. So, quicksort is obviously better. But it does matter in the case of non-primitives. So, can't just use quicksort there and thus use the fastest stable algorithm, TimSort. – Mooncrater Oct 9 '18 at 6:49
  • 4
    “quicksort requires O(1) extra space” — No, this is wrong. quicksort requires at least O(log n) extra space. This is an extremely common misconception. – Konrad Rudolph Oct 9 '18 at 7:52
  • 11
    @Mooncrater They chose to use two different algorithms because they wanted to have a stable sort. Obviously primitives are indistinguishable between equal elements, so there is no point in using a stable algorithm there. But this is not the case with the algorithm on generic objects. Also TimSort is really good at exploiting partially ordered data, which is very common in real-world scenarios... so basically the 3.7 factor is the worst-case difference between the two algorithms, which is not that bad considering also the primitivevs unboxing overhead. – Giacomo Alzetta Oct 9 '18 at 8:20
  • 7
    It should be noted that the OP’s test code is fundamentally broken. It uses (int)Math.random()*(int)1e5 which will always evaluate to zero, as (int)Math.random() will always be zero. That’s a great example for what kind of mistakes a programmer can make when not using an idiomatic construct like calling nextInt((int)1e5) (or the even simpler nextInt(100_000)) on a Random, like ThreadLocalRandom.current().nextInt(100_000), if not using a real benchmark framework in the first place. Just using actual random numbers already changes the results significantly. – Holger Oct 9 '18 at 11:47
  • 2
    @KonradRudolph the stack space is often ignored, because the stack is pre-allocated anyway (on implementations like the HotSpot JVM). Bad luck, if there is not enough… – Holger Oct 9 '18 at 12:24

There are two issues here:

Issue #1:

Under the covers, Collections.sort works by copying the collection to an array, sorting the array, then copying the array back to the collection.

Arrays.sort just sorts the array in place.

Now for a large enough array / collection, the cost of sorting (O(NlogN)) will dominate the cost of copying (O(N)). For a small array / collection, the copying becomes significant.

(This behavior may depend on the collection type. For an ArrayList, the Collections.sort implementation may be able to sort the backing array without copying data. I would need to check the source code. UPDATE - in-place sorting confirmed for ArrayList for Java 8 and later.)

Issue #2:

You are comparing sorting an int[] with sorting a List<Integer>.

This is apples and oranges. Because:

  1. Comparing two int values using relational operators is faster than comparing two Integer values using compareTo(Integer).
  2. Arrays.sort(int[]) uses a different (faster) algorithm to the one used by Arrays.sort(Object[])

If you want a fairer comparison, compare Collections.sort on an ArrayList<Integer> with Arrays.sort(Object[]) on a Integer[].

  • 5
    Collections.sort does not do copying since Java 8. It sorts the inner array in place. – ZhekaKozlov Oct 9 '18 at 7:03
  • 4
    @ZhekaKozlov in case of ArrayList we should say. While this applies here, the default implementation of List.sort still would do copying. – Holger Oct 9 '18 at 11:26
  • 2
    @Holger Are there any other subtypes of List? :) – ZhekaKozlov Oct 9 '18 at 17:00
  • 2
    @ZhekaKozlov not much that counts… Immutable lists are irrelevant, as they can’t be sorted, the lists returned by Arrays.asList(…), as well as Vector have a similar overriding method for sorting in-place, so there’s mostly LinkedList which gives you the performance drawbacks you’ve asked for, if you dare to use it. Or 3rd party mutable lists which have not been updated (don’t know of any relevant example). – Holger Oct 9 '18 at 17:08

Collection.sort() used Merge sort algorithm and Arrays.sort() uses quick sort. Quick Sort has major drawbacks when it comes to merge sort, it's not stable while it comes to non primitive. So depends on requirement we will be using either Arrays.sort() or Collection.sort() weather need to compare objects or primitives.


if you see Collections.sort() oracle doc here it reads


which means it is doing array sort and additional iteration, this implies Collections.sort() is slower than arrays.sort

  1. dumps the specified list into an array
  2. sorts the array ~ arrays.sort
  3. iterates over the list resetting each element from the corresponding position in the array

There is one thing that wasn't mentioned along the way, which is "pointer chasing", which is related to the "unboxing" part. For an array of this small size, whether you use timsort or quicksort should not make a significant difference (for primitive arrays with current CPU speeds, this is very likely not what kills your speed).

While boxing does not happen outside of the initialization in your example, the big difference happens where the data is read.

As ints are primitives, an int[] is just a contiguous piece of memory that contains the data itself, an Integer[] is a contiguous piece of memory that contains references (i.e. pointers) to the individual data objects and the Integer objects themselves can be scattered all over memory.

So for a sort operation on an int[] the CPU will fetch a chunk of memory and can operate on that directly. But for an Integer[] the CPU has to chase the pointer for each individual object and get that from memory, before it can compare it and then operate on that chunk of memory that is the array and rearrange that. This is called "pointer chasing".

It's not so much that the Integer[] requires more operations for each piece of data, like reading a value, adding a header length to the base address and getting a value from there (the CPU does pipeline these instructions very well and that hides much of its impact), it's the memory latency that kills you. Fetching each individual Integer object from a random memory location makes almost all of the difference.

Usually this is not a big deal, as usually you initialize a rather small amount of Integer[] in a tight loop and there is not a lot going on in the background, so the Integer objects are likely in close proximity in memory can be fetched into the cache and accessed from there rather quickly, but for huge arrays and lists that are created and modified all over a busy application this can make a significant difference and can come with unexpected latency spikes. You will want to avoid that if you need reliable, low latencies. For a huge number of applications however, if a sort takes a few milliseconds more, no one notices.


As you've asked for it in the comment, here's code to show that it's not about 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();
            long e1 = System.nanoTime()-t1;
            //measure refs:         
            long t2 = System.nanoTime();
            long e2 = System.nanoTime()-t2;

            // use results, so compiler can't eliminate the loops

    private static void insertionSortPrimitive(final int[] arr) {
        int i, key, j;
            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;
            key = arr[i];
            j = i - 1;
                arr[j + 1] = arr[j];
                j = j - 1;
            arr[j + 1] = key;


This "test" leaves unboxing as possible culprit.


Now this test is to show that "unboxing" is not the problem. Unboxing is just adding a few bytes of objects header to the address (out-of-order-execution and pipelining make that cost almost disappear) and getting the value from that location. In this test I use two primitive arrays, one for a reference and one for a value. So each access is indirect. This is very much like unboxing, just without adding a few bytes extra for the object header. The main difference is that the "indirect" version does not need to chase the pointer for each value on the heap, it can load both arrays and index from the refs-array into the values-array.

If pointer chasing makes the difference, rather than unboxing, then the indirect version should be faster than the objects version that does 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's 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);
            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();
            long e2 = System.nanoTime() - t2;

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

    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;
            key = arr[i];
            j = i - 1;
                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;


Result: In both of these tests, the "primitive" and "indirect" versions are faster than accessing the objects on the heap. It is to be expected that unboxing is not killing the speed, but memory latency through pointer chasing.

See also this video on project Valhalla: ("Value types and generic specialization within the JVM promise to give us better JIT code, data locality and remove the tyranny of pointer chasing.") https://vimeo.com/289667280

  • I understand your point. But can you prove it using some code? That would clarify and emphasize your point so much! – Mooncrater Oct 13 '18 at 7:32
  • @Mooncrater I have added code and a video link to explain the point. Hope that helps. – Brixomatic Oct 15 '18 at 12:17
  • Thanks @Brixomatic! Out right now. Will look into it in a while. – Mooncrater Oct 15 '18 at 14:28

Your Answer

