Difference between foreach and for loops over an IEnumerable class in C#

Question

I have been told that there is a performance difference between the following code blocks.

foreach (Entity e in entityList)
{
 ....
}

and

for (int i=0; i<entityList.Count; i++)
{
   Entity e = (Entity)entityList[i];
   ...
}

where

List<Entity> entityList;

I am no CLR expect but from what I can tell they should boil down to basically the same code. Does anybody have concrete (heck, I'd take packed dirt) evidence one way or the other?

Answer 1

foreach creates an instance of an enumerator (returned from GetEnumerator) and that enumerator also keeps state throughout the course of the foreach loop. It then repeatedly calls for the Next() object on the enumerator and runs your code for each object it returns.

They don't boil down to the same code in any way, really, which you'd see if you wrote your own enumerator.

Answer 2

Here is a good article that shows the IL differences between the two loops.

Foreach is technically slower however much easier to use and easier to read. Unless performance is critical I prefer the foreach loop over the for loop.

Answer 3

You should read a question asked yesterday:

http://stackoverflow.com/questions/43021/c-get-index-of-current-foreach-iteration

Answer 4

I think one possible situation where you might get a performance gain is if the enumerable type's size and the loop condition is a constant; for example:

const int ArraySize = 10;
int[] values = new int[ArraySize];

//...

for (int i = 0; i 

In this case, depending on the complexity of the loop body, the compiler might be able to replace the loop with inline calls. I have no idea if the .NET compiler does this, and it's of limited utility if the size of the enumerable type is dynamic.

One situation where foreach might perform better is with data structures like a linked list where random access means traversing the list; the enumerator used by foreach will probably iterate one item at a time, making each access O(1) and the full loop O(n), but calling the indexer means starting at the head and finding the item at the right index; O(N) each loop for O(n^2).

Personally I don't usually worry about it and use foreach any time I need all items and don't care about the index of the item. If I'm not working with all of the items or I really need to know the index, I use for. The only time I could see it being a big concern is with structures like linked lists.

Answer 5

The foreach sample roughly corresponds to this code:

using(IEnumerator<Entity> e = entityList.GetEnumerator()) {
    while(e.MoveNext()) {
        Entity entity = e.Current;
        ...
    }
}

There are two costs here that a regular for loop does not have to pay:

1. The cost of allocating the enumerator object by entityList.GetEnumerator().
2. The cost of two virtual methods calls (MoveNext and Current) for each element of the list.

Answer 6

In terms of allocations, it'd be better to look at this blogpost. It shows in exactly in what circumstances an enumerator is allocated on the heap.

Answer 7

One point missed here: A List has a Count property, it internally keeps track of how many elements are in it.

An IEnumerable DOES NOT.

If you program to the interface IEnumerable and use the count extention method it will enumerate just to count the elements.

A moot point though since in the IEnumerable you cannot refer to items by index.

So if you want to lock in to Lists and Arrays you can get small performance increases.

If you want flexability use foreach and program to IEnumerable. (allowing the use of linq and/or yield return).