Is Array.Copy () faster than for a loop, for 2D arrays?

Question

I recently changed

this.FieldValues = new object[2, fieldValues.GetUpperBound(1) + 1]; for (int i = 0; i < FieldCount; i++) { this.FieldValues[Current, i] = fieldValues[Current, i]; this.FieldValues[Original, i] = fieldValues[Original, i]; } 

to

  FieldValues = new object[2, fieldValues.GetLength(1)]; Array.Copy(fieldValues, FieldValues, FieldValues.Length); 

If the values ​​of Current and Original are constants 0 and 1, respectively. FieldValues ​​is a field, and fieldValues ​​is a parameter.

In the place where I used it, I found the version of Array.Copy () faster. But another developer says that he launched for-loop against Array.Copy () in a standalone program and found for-loop faster.

Is it possible that Array.Copy () is not faster? I thought this should be super-optimized!

Answer 1

In my own experience, I have found that I cannot trust my intuition about anything when it comes to performance. Therefore, I use a quick and dirty benchmarking application (which I call "StupidPerformanceTricks"), which I use to test these scenarios. This is invaluable since I made all sorts of amazing and conflicting discoveries about performance tricks. It is also important to remember that you run your test application in release mode without a debugger application, because otherwise you will not get JIT optimizations, and these optimizations can significantly affect: method A can be slower than method B in debug mode, but much faster in release mode, with optimized code.

In general, my own testing experience shows that if your array is <~ 32 elements, you will get better performance by copying your own copy cycle - presumably because you do not have the method overhead, which can be significant. However, if the loop is larger than ~ 32 elements, you will get better performance using Array.Copy (). (If you copy ints or float or similar things, you can also learn Buffer.BlockCopy (), which is ~ 10% faster than Array.Copy () for small arrays.)

But all that was said, the real answer: "Write your own tests that most closely match these exact alternatives, wrap them in each loop, give the loop enough iterations to chew for at least 2-3 seconds, and then compare the alternatives yourself" .

Answer 2

The .NET method works under the hood, I would suggest that in an optimized situation Array.Copy avoids border checks.

If you run a loop in any type of collection, by default the CLR will check to make sure that you are not passing the end of the collection, and then the JIT will either have to evaluate the runtime or emit code that does not need to be checked. (check out the article in my comment for more details on this)

You can change this behavior, but usually it’s not so much. If you are not in a tightly executed inner loop where every millisecond is considered to be.

If the array is massive, I would use Array.Copy if it is small, or should do the same.

I really think that it limits the verification that you are creating different results for you.

Answer 3

In your specific example, there is a factor that can (theoretically) indicate that the for loop executes faster.

Array.Copy is an O (n) operation, while a for loop is O (n / 2), where n is the total size of your matrix.

Array.Copy requires a loop through all the elements in your two-dimensional array, because:

When copying between multidimensional arrays, the array behaves like a long one-dimensional array, where the rows (or columns) are conceptually laid out to the end. For example, if an array has three rows (or columns) with four elements each, copying six elements from the beginning of the array will copy all four elements of the first row (or column) and the first two elements of the second row (or column).