|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Enumerator vs ForNext vs ForEachHi,
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. Show quoteHide quote "rawCoder" <rawCo***@hotmail.com> wrote in message news:%23IP7pcEQFHA.3076@TK2MSFTNGP14.phx.gbl... > Hi, > > Which is better in terms of performance. > > Iterating over Enumerator > ForNext loop (using indexer) > ForEach loop > > Thanx > rawCoder > > 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). -- Show quoteHide quoteSincerely, Dmytro Lapshyn [Visual Developer - Visual C# MVP] "rawCoder" <rawCo***@hotmail.com> wrote in message news:%23IP7pcEQFHA.3076@TK2MSFTNGP14.phx.gbl... > Hi, > > Which is better in terms of performance. > > Iterating over Enumerator > ForNext loop (using indexer) > ForEach loop > > Thanx > rawCoder > > 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. -- Show quoteHide quote- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com "rawCoder" <rawCo***@hotmail.com> wrote in message news:%23IP7pcEQFHA.3076@TK2MSFTNGP14.phx.gbl... > Hi, > > Which is better in terms of performance. > > Iterating over Enumerator > ForNext loop (using indexer) > ForEach loop > > Thanx > rawCoder > > 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[i] ... } 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[i] = this._internalArray[i].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!) Bruce,
This code: int numItems = myClass.Property.Length; for (int i = 0; i < numItems; i++) { ... do something with myClass.Property[i] ... } will always be less performant than: for (int i = 0; i < myClass.Property.Length) { ... do something with myClass.Property[i] ... } Because a subtle little thing called bounds checking. Show quoteHide quote "Bruce Wood" wrote: > 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[i] ... > } > > 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[i] = this._internalArray[i].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!) > > Bruce Wood <brucew***@canada.com> wrote:
> 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[i]; /// } The array access x[i] 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 -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too What if I redimension x within the loop thus changing it's length?
Show quoteHide quote "Jon Skeet [C# MVP]" wrote: > Bruce Wood <brucew***@canada.com> wrote: > > 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[i]; > /// > } > > The array access x[i] 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 > > -- > Jon Skeet - <sk***@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too > Dennis <Den***@discussions.microsoft.com> wrote:
> 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. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too 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 Show quoteHide quote "Jon Skeet [C# MVP]" wrote: > Dennis <Den***@discussions.microsoft.com> wrote: > > 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. > > -- > Jon Skeet - <sk***@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too > 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 Show quoteHide quote "rawCoder" <rawCo***@hotmail.com> wrote in message news:%23IP7pcEQFHA.3076@TK2MSFTNGP14.phx.gbl... > Hi, > > Which is better in terms of performance. > > Iterating over Enumerator > ForNext loop (using indexer) > ForEach loop > > Thanx > rawCoder > > 
Other interesting topics
|
|||||||||||||||||||||||
