CodeProject: FOREACH Vs. FOR (C#). Free source code and programming help

Report Article

Discuss

Send to a friend

39 votes for this Article.

Popularity: 4.72 Rating: 2.97 out of 5

Introduction

In my experience, there are two kinds of programmers. Those who write something to get the work done and those who want to write good code. But, here we get a big question. What is good code? Good code comes from good programming practices. What are good programming practices? Actually, my aim here is not to talk about good programming practices (I’m planning to write something related to that in future!), rather to talk more about writing something which will be more effective. I'm only going to look more deeper of two loops which are commonly used nowadays, and their differences in the aspect of performance.

Background

Must be familiar with IL and assembly code. Also, better to have a good knowledge on how .NET framework works. Some knowledge of JIT is also needed to understand what is exactly happening.

Using the code

I’m going to take a very small piece of code for two popular looping statements for and foreach. We will look some code and will see what it does, more in detail about the functionality.

FOR

int[] myInterger = new int[1];
int total = 0;
for(int i = 0; i < myInterger.Length; i++)
{
    total += myInterger[i];
}

foreach

int[] myInterger = new int[1];
int total = 0;
foreach(int i in myInterger) 
{
    total += i;
}

Both codes will produce the same result. foreach is used on top of collections to traverse through while for can be used on anything for the same purpose. I’m not going to explain whatsoever about the code. Before going in more deeper, I think all of you are familiar with ILDasm which is used to generate IL code, and CorDbg tool which is normally used to generate JIT compiled code.

The IL code produced by C# compiler is optimized up to certain extend, while leaving some part to JIT. Anyway, this is not really what matters to us. So, when we talk about the optimization, two things we must consider. First is C# compiler and the second is JIT.

So, rather than looking more deep into IL code, we will see more about the code which is emitted by JIT. That is the code which will run on our machine. I’m now using AMD Athlon 1900+. The code highly depends on our hardware. Therefore, what you may get from your machine may differ from mine up to a certain extend. Anyway, the algorithms wont change that much.

In variable declaration, foreach has five variable declarations (three Int32 integers and two arrays of Int32) while for has only three (two Int32 integers and one Int32 array). When it goes to loop through, foreach copies the current array to a new one for the operation. While for doesn't care of that part.

Here, I’m going into the exact difference between the codes.

FOR

Instruction                           Effect

cmp     dword ptr [eax+4],0           i<myInterger.Length
jle     0000000F
mov     ecx,dword ptr [eax+edx*4+8]   total += myInterger[i]
inc     edx                           ++i
cmp     esi,dword ptr [eax+4]         i<myInterger.Length
jl      FFFFFFF8

I’ll explain what is happening here. The esi register which holds the value of i and the length of myInteger array are compared at two stages. The first one is done only once to check the condition and if the loop can continue, the value is added. For the loop, it is done at the second stage. Inside the loop, it is well optimized and as explained, the work is done with perfect optimization.

foreach

Instruction                            Effect

cmp     esi,dword ptr [ebx+4]          i<myInterger.Length
jl      FFFFFFE3
cmp     esi,dword ptr [ebx+4]          i<myInterger.Length 
jb      00000009
mov     eax,dword ptr [ebx+esi*4+8] 
mov     dword ptr [ebp-0Ch],eax  
mov     eax,dword ptr [ebp-0Ch]
add     dword ptr [ebp-8],eax          total += i
inc     esi                            ++i
cmp     esi,dword ptr [ebx+4]          i<myInterger.Length
jl      FFFFFFE3

Anyone will say that both are not the same. But we will look why it differs from the for loop. The main reason for the difference is that both of them are differently understood by the compiler. The algorithm they are using is different. Two compare statements one after the other is unnecessary. It is doing the same thing again and again for no reason!

cmp                    esi,dword ptr [ebx+4]   
jl                         FFFFFFE3
cmp                    esi,dword ptr [ebx+4]

It also uses some unnecessary move statements which also may (not always, but depends) reduce the performance of the code. foreach is thinking everything as a collection and treating them as a collection. I feel, that will also reduce the performance of the work.

Therefore, I strongly feel if you are planning to write high performance code that is not for collections, use for loop. Even for collections, foreach may look handy when using, but it's not that efficient. Therefore, I strongly recommend everyone to use for loop rather than foreach at any stage.

Points of Interest

Actually, I did a small research on the performance issue of codes mainly on .NET languages. While I was testing, I found that it was really a must to know how JIT works and to debug the code generated by JIT compiler. It took some time to understand the code.

History

This is submitted on 19th of April 2004.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Chester Ragel

Occupation:	Web Developer
Location:	Singapore

Other popular C# articles:

Asynchronous Method Invocation
How to use .NET to call methods in a non-blocking mode.
IconLib - Icons Unfolded (MultiIcon and Windows Vista supported)
Library to manipulate icons and icons libraries with support to create, load, save, import and export icons in ico, icl, dll, exe, cpl and src format. (Windows Vista icons supported).
I/O Ports Uncensored - 1 - Controlling LEDs (Light Emiting Diodes) with Parallel Port
Controlling LEDs (Light Emiting Diodes) with Parallel Port
100% Reflective Class Diagram Creation Tool
100% Reflective Class Diagram Creation Tool
I/O Ports Uncensored Part 2 - Controlling LCDs (Liquid Crystal Displays) and VFDs (Vacuum Fluorescent Displays) with Parallel Port
Controlling LCDs (Liquid Crystal Displays) and VFDs (Vacuum Fluorescent Displays) with Parallel Port

Article Top

You must Sign In to use this message board.

Msgs 1 to 25 of 47 (Total in Forum: 47) (Refresh)

FirstPrevNext

link to a correct article

korsuas

1:15 16 May '08

I like the visual explanations on this[^] article. Much better than this code project mistake.
Sign In·View Thread·PermaLink

foreach copies the current array to a new one

PIEBALDconsult

10:43 15 May '08

You say: " foreach copies the current array to a new one " I don't see where in the IL it does that. And have you retested with newer versions?
Sign In·View Thread·PermaLink

Technical Details

mercede

23:16 19 Nov '07

The article gives very false information. Here is the truth.

For-Each loop is always slower then a plain for loop. In case of a For loop the CX register is loaded with the highest value (or the reverse) and then after every iteration the CX register is incremented/decremented. thats not much work.

The For-Each loop it is just a language construct that translates something that is closer to a while loop. For-each works only on objects that support IEnumerable. The object is first queried for the IEnumeable which returns an IEnumerator which exposes functions like Next, Reset, Item, Count etc. For loop works by calling these functions repeatedly. a function call is almost always expensive and results in a lot of work (pushing registers on stack, saving return address etc).

I'm not sure if the .NET compiler expands the for-each function inline. If it does then the speed is slightly increased but the plain for loop is almost always the winner.

Second thing is when you are checking the code execution speed the coding timers can never give the correct results. as there might be many factors effecting the performance. The correct way to measure the speed of code is by using the appropiate profiler.

Article is out of date and now INCORRECT

His Divine Shadow

0:31 27 Feb '07

With release builds using Visual Studio 2005, foreach is FASTER than for.

This simple test program demonstrates it:


private void button1_Click_1(object sender, EventArgs e)
{
    Stopwatch stopwatch = new Stopwatch();

    int[] array = new int[10000000];

    stopwatch.Start();
    Test1(array);
    stopwatch.Stop();
    MessageBox.Show("Elapsed 1 = " + stopwatch.ElapsedMilliseconds);

    stopwatch.Reset();
    stopwatch.Start();
    Test2(array);
    stopwatch.Stop();
    MessageBox.Show("Elapsed 2 = " + stopwatch.ElapsedMilliseconds);
}

int Test1(int[] array)
{
    int total = 0;

    for (int i = 0; i < array.Length; ++i)
        total += array[i];

    return total;
}

int Test2(int[] array)
{
    int total = 0;

    foreach (int value in array)
        total += value;

    return total;
}

Results on my system (release build):

for loop: 41 ms
foreach loop: 18 ms

So the foreach loop is MORE THAN TWICE AS FAST as the for loop.

Time to put this one to bed and STOP TELLING PEOPLE STUFF THAT'S JUST PLAIN WRONG!

Re: Article is out of date and now INCORRECT

snarfblam

16:45 27 Feb '07

It sounds like you have a vendetta with a minor foreach misconception. It is probably true that foreach is faster than (or at least as fast as) a for loop when working with arrays.

You are both missing the bigger picture, though. When working with other types of collections, how foreach actually works is up to the designer of the collection class: the person who implements IEnumerator. When you consider that, well, there really is not way to say which is faster. Besides, even when working with arrays, the speed will to some extent depend on how you use the value, but what will be even more important 9 out of 10 times is that when using a for loop you have access to the index of the item you are examining and when using a foreach loop the code will usually be simpler. Use the method that results in the simplest code. If performance is a serious issue, you should try a few variants and see which is best, rather than depending on a generalization.

5.00/5 (2 votes)

Re: Article is out of date and now INCORRECT

His Divine Shadow

1:14 28 Feb '07

That's fair enough - my beef is with saying that foreach is slower when it isn't. You have to instrument things!

I in fact made an error with my test program that I posted above.

I should have put the two tests in a loop that ran for 100 or more iteration to eliminate distortions caused by JIT.

If you do so, it turns out that foreach is only marginally faster than for, not twice as fast.

However, it is certainly not slower. Smile

Re: Article is out of date and now INCORRECT

The Limey

23:00 6 Apr '07

Not a good test, reverse the test in your code, test array 2 first and then test array 1. The for is more than twice as fast as the foreach. Maybe its your test code thats wrong? He who laughs last thinks slowest.
Sign In·View Thread·PermaLink

Re: Article is out of date and now INCORRECT

Niclars

1:10 5 Jul '07

What you will find is the C# compiler doesnt use the enumerator pattern when working on arrays - a simple look at the IL will show this.

private static void EnumerationExample()
{
int[] ints = new int[50];

foreach(int i in ints)
{
int p = 0;
p = i + p;
}

Console.WriteLine("A");

List ints2 = new List(new int[50]);

foreach (int i in ints2)
{
int p = 0;
p = i + p;
}
}

In a pretty decent programmatic profiling framework I have written I can prove that on average the normal for-loop is over 3x quicker (with the normal caveats on performance related issues associated with profiling in a managed environment). Iterating a loop with 1000000 items in it, 100 times shows me on my box that the enumeration on average takes 112 milliseconds, while the for-each only takes 35. Clearly marginal in most simple situations, but definitely worth considering when building real-time applications...you must also consider the impact of the GC for the new enumeration objects in the non-for-loop example.

Nick.
www.lab49.com

1.50/5 (2 votes)

Missing the point

hamacatak

5:10 9 Aug '06

The point of for each is that you don't need to know how the object works to iterate through it. OK the performance is a teeny weeny bit slower (but very very unlikely to be a bottleneck) but the advantage is that if you swap the array for another container type which doesn't use numerical indexes then you don't need to change any code.
Sign In·View Thread·PermaLink	5.00/5 (1 vote)

A counterpoint to this article

Joe Woodbury

8:10 3 Dec '04

First, without actually benchmarking a section of assembly, any conclusions about its performance on modern processors can only be ballpark in nature; with caching, deep pipelines, branch predicting, etc. code may actually be faster than it first appears.

Second, the code in your 'for' example is missing an add dword ptr [ecx+8],eax instruction. The 'foreach' example appears to be based on debug IDL, not optimized IDL (though that's only speculation; but my results differ from what it shown.)

Third, in the 'foreach' example (using my optimized assembly), the redundant check is used only the first time through. From then on it branches back to the mov eax... instruction (just after the jb instruction. In my optimized version, this extra code isn't present.)

In my code, the only substantial difference between two algorithms is the 'for' loop has an extra bounds check at the top of the loop (to throw, I presume, an out-of-bounds exception should the need arise.)

Finally, I have done many benchmarks with 'for' and 'foreach'. 'foreach' is almost always faster. I've concluded that 'for' should be used if you need to modify the contents of the array and/or you need to readily know the index of an item. Otherwise, foreach is usually a better choice. But, as always, if performance is a concern, benchmark both and even consider other possibilities which may be even faster and/or more efficient.

PS. I know 80x86 assembly extremely well. For several years I had a job where everything was written in 80x86 assembly (I've also done 6502 and 68000 assembly professionally and some Z80 on the side.)

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

Have you considered....

Colin Angus Mackay

12:43 20 Apr '04

For very large numbers of iterations (and this is important, because for small iterations the setup and tear-down portions of a loop become significant percentages for the loop processing time) you could try:

try
{
    for(int i = myVeryLargeArray.Length; ; i--)
    {
        // Do something with the array.
    }
}
catch
{
}

Notice that there is no exit condition check in the for statement. So, what happens when i becomes -1?

** BANG ** IndexOutOfRangeException

For VERY LARGE numbers of iterations the cost of the exception can be cheaper than the cost of an exit condition check on each iteration.

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar

Coming soon: The Second EuroCPian Event[^].

Re: Have you considered....

Colin Angus Mackay

21:43 20 Apr '04

paulb wrote:
Sorry, but I think this is just totally ugly

Don't appologies. It is ugly. I never said otherwise.

paulb wrote:
You are using exception handling as a method of normally exiting a loop

Yes, that was the point of my post.

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar

Coming soon: The Second EuroCPian Event

Re: Have you considered....

Norm Almond

22:35 20 Apr '04

and it's gotta be a whole lot slower.
Sign In·View Thread·PermaLink

Re: Have you considered....

Colin Angus Mackay

23:11 20 Apr '04

Like I said - for VERY LARGE iterations.... "You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar Coming soon: The Second EuroCPian Event
Sign In·View Thread·PermaLink

Re: Have you considered....

Chester Ragel

23:15 20 Apr '04

I don't understand...
Sign In·View Thread·PermaLink

Re: Have you considered....

Colin Angus Mackay

23:59 20 Apr '04

What is the cost of performing a bounds check in each loop. In other words what is the difference between:

for(int i = 0; i<largeArrayUpperBound; i++)
{
}

and

for(int i = 0; ; i++)
{
}

So what is the difference cost over millions of cycles?

Since an exception is thrown anyway when the index of the array is out of bounds (we can infer that a bounds check is performed when you access the array's indexer) so why duplicate the effort? Why not just wait for the exception to be thrown and catch it?

Like I said somewhere else, I'm not crazy to actually put this in a production environment as you need to be able to say that consistently you will have all those millions of cycles each time this code is executed. But from an academic point of view it is interesting to see what happens.

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar

Coming soon: The Second EuroCPian Event

Re: Have you considered....

Norm Almond

2:15 21 Apr '04

allowing the clr to throw exceptions can also be VERY time consuming.
Sign In·View Thread·PermaLink

Re: Have you considered....

Chester Ragel

2:22 21 Apr '04

And also its not a good thing to allow throwing exception. Another thing, `for(int i=0; i < myArray.Length; i++){}` is equal to `for(int i=0; i < arrayLength; i++){}` after JIT compiled.
Sign In·View Thread·PermaLink

Re: Have you considered....

Colin Angus Mackay

2:48 21 Apr '04

Norm Almond wrote: allowing the clr to throw exceptions can also be VERY time consuming That is why you need to have millions of cycles in the iteration, otherwise it is just not worth it. "You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar Coming soon: The Second EuroCPian Event
Sign In·View Thread·PermaLink

Re: Have you considered....

danny213845

19:47 3 Jun '04

Hi Colin, Exception is not for capturing one bad written logic. Exception is for capturing unexpected logical error. Beside Exception captured slow down program running a lot. Therefore, programmer needs to determine when is the time to use try...catch
Sign In·View Thread·PermaLink

Re: Have you considered....

Colin Angus Mackay

20:56 3 Jun '04

Like I've said elsewhere in this thread. This is only an academic excercise. I don't expect to ever use or see this anywhere in production code, simply because you need to guarantee that there will be sufficient numbers of iterations in advance. For some actual statistics go here[^]

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar

The Second EuroCPian Event will be in Brussels on the 4th of September

Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!

Re: Have you considered....

JohnLWhitaker

8:53 14 Jun '07

Hmmm...what is wrong with this logic???

>>>>>>>>>>>>>>
Exception is not for capturing one bad written logic.
Exception is for capturing unexpected logical error.
Beside Exception captured slow down program running a lot.
Therefore, programmer needs to determine when is the time to use try...catch
>>>>>>>>>>>>>>

Ex = Exception
BL = Bad Logic
ULE = Unexpected Logical Error(s)
SP = Slows Program
PR = PRogrammer
TC = Try/Catch
~ = NOT

Premise: Ex --> ~BL
Premise: Ex --> ULE
Premise: Ex --> SP
_____________________________
Conclusion: P --> (TC or ~TC)
Contrapositive: (~TC and TC) --> ~P

Re: Have you considered....

snarfblam

16:55 27 Feb '07

There is a major misunderstanding on your part here. Both of the above code listings are less than desirable. The ideal code listing would be in the form of:

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

The important thing here is that you use the Length property of the array in the terminating condition. When you do this, the JIT compiler can infer that you are iterating over an array and bounds checks (the bounds checks that are performed each time you access the array within the loop) can be eliminated. What's more, the compiler knows that the array bounds are immutable, so it will optimize away the property getter function call that you have coded into the terminating condition. The result? Code that executes, at worst, the same speed as your "optimized" code, or faster if there are more than one array accesses in the loop, minus the cost of an exception (which can be quite exceptional if it is the first exception thrown by the application), plus more readable code. The moral of the story? Don't try to micro-optimize your dot-net code. The JIT compiler is smarter than you think, and unless you know all the nuances it is hard to out-smart it.

Re: Have you considered....

Colin Angus Mackay

22:53 27 Feb '07

snarfblam wrote:
The important thing here is that you use the Length property of the array in the terminating condition. When you do this, the JIT compiler can infer that you are iterating over an array and bounds checks (the bounds checks that are performed each time you access the array within the loop) can be eliminated. What's more, the compiler knows that the array bounds are immutable, so it will optimize away the property getter function call that you have coded into the terminating condition.

So, what you are saying is that if I use array.Length in my loop, the compiler will magically remove the bounds check in the array's indexer method. I really don't think that's going to happen. The compiler may be able to make many optimisations but I seriously doubt that is one of them.

However, if you can cite a credible soure on your statement, I'll be happy to revise my opinion.

Anyway, my example was purely academic (as I stated many times in this thread). It does perform as I described as I tested is many many times over two and a half years ago. It is not something I have ever put into production, the experiment was done purely out of curiosity and I got consistent results from it.

snarfblam wrote:
plus more readable code

Exactly - And, I'll continue to repeat myself, the exercise was purely academic. It was never indended for production code.

snarfblam wrote:
The moral of the story? Don't try to micro-optimize your dot-net code. The JIT compiler is smarter than you think, and unless you know all the nuances it is hard to out-smart it.

That is absolutely correct. I never disagreed with that statement. As I said already in this thread. The example was purely out of curiosity and I never urged anyone to use it in production code. In fact I warned them against it.

Upcoming events:
* Glasgow: Geek Dinner (5th March)
* Edinburgh: Web Security Conference Day for Windows Developers (12th April)

My: Website | Blog | Photos

5.00/5 (2 votes)

Re: Have you considered....

snarfblam

12:28 2 Mar '07

Thank you for your itemized reply, but it wasn't necessary. You needn't repeat yourself. Just because I made a statement does not mean that I believe that you disagree with it or think otherwise. I never said that you proposed this be used in production code, and the aim of the "moral of the story" is that the JIT compiler is smarter than you think, rather than "don't try to micro-optimize your dot-net code."

As far as the optimized bounds check, this is very well known and I will not cite a reference. This is the classic example in the DotNet world of why we shouldn't micro-optimize. It is almost cliche. A google search will suffice if you don't believe me. You won't see this optimization reflected in the IL code, either. It is a JIT optimization. I also don't know whether it is present in other distributions of the CLR or version 1.0.

I appreciate the academic value of the exercise and the fact that you took the time to write an article about it. To that end it is only fair to mention that this optimization will backfire in the end.

1.00/5 (2 votes)

Last Visit: Friday, November 21, 2008 10:57 AM Last Update:Friday, November 21, 2008 10:57 AM

1 Next »

General News Question Answer Joke Rant Admin