You will not see anything in the Java bytecode to explain. Things like this can be the effect of either the machine instructions (as created by the just-in-time JIT compiler) or even the microprocessor (particularly the effect of one of the processor caches).

One thing to note here is that in this sort algorithm, for each iteration of the loop, only A[j] needs to be loaded since A[j-1] was loaded in the last iteration. So the most recently loaded value was A[j] (assuming the fact that I just stated has been taken advantage at some level). Therefore, within the loop, the algorithm that stores A[j] first may behave differently because that values was most recently loaded by the loop check, so that value is more likely to remain in a register or in a processor cache, or be subject to just a single memory load due to optimizations in the JIT-generated machine code.

It is true (as the above answer demonstrates) that is very difficult to know exactly what series of machine instructions are being executed (the JIT has several different levels of compilation, each with different optimizations, based on how often a method is executed, and there are many different JIT optimizations which may interact resulting in different machine code). It is also difficult to know which memory accesses must go to RAM and which are avoided by memory cache hits in the processor. No doubt some combination of the above effects are affecting the performance here. The order of an algorithm has the most effect on performance, but beyond that, there are many optimizations in the JIT and the microprocessor that can affect performance, not all of them obvious to predict.

My instinct is that this is the result of the processor's memory cache working better with your sequence of operations, in part due to the fact that only A[j] needs to be loaded with each loop iteration.

TL;DR

Your experiment isn't valid, there are many variables that may affect the result. It's best that you utilize a microbenchmarking tool such as Caliper or JMH. I used such a tool for checking which method is faster to create indentation

The difference between yours and your professor's is negligible.

The experiment

For my experiment I had 745,038 data points. I created 3 tests, yours, your instructor's version and Arrays.sort() that is part of the JDK.

https://microbenchmarks.appspot.com/runs/8b8c0554-d3f1-4339-af5a-fdffd18dd053

Based on the results your runtime was: 1,419,867.808 ns Your instructor was: 1,429,798.824 ns

So we're talking about 0.01 ms.

The instructor's just had less variance between the runs.

The JDK Arrays.sort() was slower by a larger magnitude at 1,779,042.513 ns which is 0.300ms slower than yours.

Here is the code I used to do the microbenchmark in Caliper below.

package net.trajano.caliper.test; import java.io.DataInputStream; import java.io.EOFException; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Paths; import java.util.ArrayList; import java.util.Arrays; import java.util.List; import com.google.caliper.BeforeExperiment; import com.google.caliper.Benchmark; import com.google.caliper.api.VmOptions; import com.google.caliper.runner.CaliperMain; @VmOptions("-XX:-TieredCompilation") public class SortBenchmark { public static int[] insertionSort(final int[] A) { // Check for illegal cases if (A == null || A.length == 0) { throw new IllegalArgumentException("A is not populated"); } for (int i = 0; i < A.length; i++) { int j = i; while (j > 0 && A[j - 1] > A[j]) { final int temp = A[j - 1]; A[j - 1] = A[j]; A[j] = temp; j--; } } return A; } public static int[] insertionSortInstructor(final int[] A) { // Check for illegal cases if (A == null || A.length == 0) { throw new IllegalArgumentException("A is not populated"); } for (int i = 0; i < A.length; i++) { int j = i; while (j > 0 && A[j - 1] > A[j]) { final int temp = A[j]; A[j] = A[j - 1]; A[j - 1] = temp; j--; } } return A; } @BeforeExperiment void setUp() throws IOException { try (final DataInputStream dis = new DataInputStream( Files.newInputStream(Paths.get("C:/Program Files/iTunes/iTunes.exe")))) { final List<Integer> list = new ArrayList<Integer>(); while (true) { try { list.add(dis.readInt()); } catch (final EOFException e) { break; } } data = list.stream().mapToInt(i -> i).toArray(); System.out.println("Data size = " + data.length); } } // data to sort private static int[] data; @Benchmark public void insertionSort(final int reps) { for (int i = 0; i < reps; i++) { insertionSort(data); } } @Benchmark public void insertionSortInstructor(final int reps) { for (int i = 0; i < reps; i++) { insertionSortInstructor(data); } } @Benchmark public void jdkSort(final int reps) { for (int i = 0; i < reps; i++) { Arrays.sort(data); } } public static void main(final String[] args) { CaliperMain.main(SortBenchmark.class, args); } } 

Aside

To be honest I was surprised at the result, that the JDK was slower. So I took a look at the source code. It appears there's three sorting algorithms being used by the JDK depending on the thresholds (merge sort, quicksort for less than 286 elements and insertion sort for less than 47 elements).

Since the data set I had was pretty large to begin with, merge sort goes first which has O(n) space complexity in the form of a second copy of the array. As such it is likely extra heap allocations that are causing the extra time.