Why does the second for loop always execute faster than the first one?

Question

I was trying to figure out if a for loop was faster than a foreach loop and was using the System.Diagnostics classes to time the task. While running the test I noticed that

Answer 1

Probably because the classes (e.g. Console) need to be JIT-compiled the first time through. You'll get the best metrics by calling all methods (to JIT them (warm then up)) first, then performing the test.

As other users have indicated, 4 passes is never going to be enough to to show you the difference.

Incidentally, the difference in performance between for and foreach will be negligible and the readability benefits of using foreach almost always outweigh any marginal performance benefit.

Answer 2

You should be using the StopWatch to time the behavior.

Technically the for loop is faster. Foreach calls the MoveNext() method (creating a method stack and other overhead from a call) on the IEnumerable's iterator, when for only has to increment a variable.

Answer 3

I am not so much in C#, but when I remember right, Microsoft was building "Just in Time" compilers for Java. When they use the same or similar techniques in C#, it would be rather natural that "some constructs coming second perform faster".

For example it could be, that the JIT-System sees that a loop is executed and decides adhoc to compile the whole method. Hence when the second loop is reached, it is yet compiled and performs much faster than the first. But this is a rather simplistic guess of mine. Of course you need a far greater insight in the C# runtime system to understand what is going on. It could also be, that the RAM-Page is accessed first in the first loop and in the second it is still in the CPU-cache.

Addon: The other comment that was made: that the output module can be JITed a first time in the first loop seams to me more likely than my first guess. Modern languages are just very complex to find out what is done under the hood. Also this statement of mine fits into this guess:

But also you have terminal-outputs in your loops. They make things yet more difficult. It could also be, that it costs some time to open the terminal a first time in a program.

Answer 4

1. I would not use DateTime to measure performance - try the Stopwatch class.
2. Measuring with only 4 passes is never going to give you a good result. Better use > 100.000 passes (you can use an outer loop). Don't do Console.WriteLine in your loop.
3. Even better: use a profiler (like Redgate ANTS or maybe NProf)

Answer 5

I don't see why everyone here says that for would be faster than foreach in this particular case. For a List<T>, it is (about 2x slower to foreach through a List than to for through a List<T>).

In fact, the foreach will be slightly faster than the for here. Because foreach on an array essentially compiles to:

for(int i = 0; i < array.Length; i++) { }

Using .Length as a stop criteria allows the JIT to remove bounds checks on the array access, since it's a special case. Using i < 4 makes the JIT insert extra instructions to check each iteration whether or not i is out of bounds of the array, and throw an exception if that is the case. However, with .Length, it can guarantee you'll never go outside of the array bounds so the bounds checks are redundant, making it faster.

However, in most loops, the overhead of the loop is insignificant compared to the work done inside.

The discrepancy you're seeing can only be explained by the JIT I guess.

Answer 6

The reason why is there are several forms of overhead in the foreach version that are not present in the for loop

• Use of an IDisposable.
• An additional method call for every element. Each element must be accessed under the hood by using IEnumerator<T>.Current which is a method call. Because it's on an interface it cannot be inlined. This means N method calls where N is the number of elements in the enumeration. The for loop just uses and indexer
• In a foreach loop all calls go through an interface. In general this a bit slower than through a concrete type

Please note that the things I listed above are not necessarily huge costs. They are typically very small costs that can contribute to a small performance difference.

Also note, as Mehrdad pointed out, the compilers and JIT may choose to optimize a foreach loop for certain known data structures such as an array. The end result may just be a for loop.

Note: Your performance benchmark in general needs a bit more work to be accurate.

• You should use a StopWatch instead of DateTime. It is much more accurate for performance benchmarks.
• You should perform the test many times not just once
• You need to do a dummy run on each loop to eliminate the problems that come with JITing a method the first time. This probably isn't an issue when all of the code is in the same method but it doesn't hurt.
• You need to use more than just 4 values in the list. Try 40,000 instead.