Enumerator vs ForNext vs ForEach

  • Thread starter Thread starter rawCoder
  • Start date Start date
R

rawCoder

Hi,

Which is better in terms of performance.

Iterating over Enumerator
ForNext loop (using indexer)
ForEach loop

Thanx
rawCoder
 
I'm guessing the regular for loop with just incrementing a variable.

I guess you can test this pretty easily though without having to ask in a
newsgroup. Just run some tests on large sets of data.
 
Hi,

I remember the second was the fastest, but some people claim the 1st is
equally performant (and the 3rd actually implies the 1st with the gluing
code compiled for you in the background).
I'd suggest that you wrote a simple performance test using all these
approaches and post your results here.

Also, you can consult the 'Improving the performance of .NET applications'
e-book (not exact title, should be available from the Patterns and Practices
website).
 
rawCoder,

It's hard to say. Each implementation of IEnumerable/IEnumerator will
be different. Each collection object can handle enumerations differently.

However, I would think that most implementations will just keep an
internal counter in the implementation of IEnumerator and then access the
collection using that internal counter (which is the same as using a for
each loop). This assumes that the collection is suited for this kind of
iteration (a tree structure would be completely different, for example).

Generally speaking though, it is better to use foreach, because if the
implementation of IEnumerator also implements IDisposable, it will handle
the disposing of the implementation as well.

Hope this helps.
 
The for loop using an indexer can introduce some serious performance
problems, but only in some situations. Take for example iterating over
an array returned by a property:

int numItems = myClass.Property.Length;
for (int i = 0; i < numItems; i++)
{
... do something with myClass.Property ...
}

This can incur a serious performance penalty if myClass builds a return
array for every reference to myClass.Property. However,

foreach (Item t in myClass.Property)
{
... do something with t...
}

incurs no such penalty, because the array is fetched from
myClass.Property once and then the enumerator ranges over the one
array.

(To wit, I'm talking about a property that may look like this:

public class TheClass
{
public Item[] Property
{
get
{
Item[] result = new Item[this._internalArray.Length];
for (int i = 0; i < this._internalArray.Length; i++)
{
result = this._internalArray.Clone();
}
return result;
}
}
}

As you can see the array gets copied every time, which makes the for
loop with indexer in the code using this property a real performance
hog!)
 
rawCoder,

I don't know how it is implemented in dotNet, however in past were things
like foreach often implementing direct the actual address length to add to
the previous.

I never changed my behaviour that I use instructions as foreach when I don't
need an indexer. When that is not done, than I loose nothing, and when that
in future is done, there is only some benefit.

However just a very simple thought,

Cor
 
from ScaleNet.pdf
Page 251-252
Chapter5: Improving Managed Code Performance ( Collection Guidelines )

Consider for Instead of foreach
Use for instead of foreach (C#) to iterate the contents of arrays or
collections in
performance critical code, particularly if you do not need the protections
offered by
foreach.
Both foreach in C# and For Each in Visual Basic .NET use an enumerator to
provide
enhanced navigation through arrays and collections. As discussed earlier,
typical
implementations of enumerators, such as those provided by the .NET
Framework,
will have managed heap and virtual function overhead associated with their
use.
If you can use the for statement to iterate over your collection, consider
doing so in
performance sensitive code to avoid that overhead.

Just one question? The enumerator discussed in above para .. is it the same
as IEnumerable.GetEnumerator. Because then foreach must be the most slowest
option as in the same section of the document it has one section named
"Consider Enumerating Overhead."

Sorry didnt read it first b4 posting.

HTH
rawCoder
 
Bruce Wood said:
Tell me more. How does bounds checking come into it?

In certain cases (which I don't believe are applicable here, as the
value of the property could easily change between iterations) the
compiler can remove a lot of bounds checking. Say you have:

string[] x = ...;
for (int i=0; i < x.Length; i++)
{
string y = x;
///
}

The array access x would normally need to go through a bounds check,
to make sure you're not doing x[-1] or x[1000000]. With the above
(common) code, the JIT compiler can spot that there's no way i is ever
going to be outside the bounds of the array, so can eliminate the
bounds check. I suspect this requires that:

1) x is a local variable, or perhaps a readonly variable.
(Otherwise the value could change between the comparison with x.Length
and the array access.)

2) i and x aren't modified within the body of the loop
 
What if I redimension x within the loop thus changing it's length?

Jon Skeet said:
Bruce Wood said:
Tell me more. How does bounds checking come into it?

In certain cases (which I don't believe are applicable here, as the
value of the property could easily change between iterations) the
compiler can remove a lot of bounds checking. Say you have:

string[] x = ...;
for (int i=0; i < x.Length; i++)
{
string y = x;
///
}

The array access x would normally need to go through a bounds check,
to make sure you're not doing x[-1] or x[1000000]. With the above
(common) code, the JIT compiler can spot that there's no way i is ever
going to be outside the bounds of the array, so can eliminate the
bounds check. I suspect this requires that:

1) x is a local variable, or perhaps a readonly variable.
(Otherwise the value could change between the comparison with x.Length
and the array access.)

2) i and x aren't modified within the body of the loop
 
Dennis said:
What if I redimension x within the loop thus changing it's length?

You can't change the size of an array object - you'd have to set x to a
new value, which comes under the second restriction I mentioned.
 
Right! You'll find also that in the following, j=11 when the loop exits so
you can't change a value either:

Dim i, j As Integer
Dim k As Integer = 10
For i = 0 To k
j = j + 1
If j = 5 Then k = 15
Next

J will = 11 and k will = 15
 
Back
Top