Have you tried this with a non-primitive type? I wonder if unboxing the int skews the results.

aaronjensen,

There is no boxing/unboxing happening here.

ah yea, you're right. my head was in a distant land.

Pingback from  Arjan`s World    » LINKBLOG for November 19, 2008

I haven't used PostSharp yet but maybe it could be used to swap out loop code without mangling code readability?

Very Nice Article

After modifying your tests to eliminate JIT-compilation (pre-run all the test methods before the measurements) and compiling them in "Release" I got different results. Foreach over List is still slower than everything else, but not as dramatically:

IterateForeachOnList:                     2398126

IterateForOnListWithoutCountOptimization: 1317010

IterateForOnListWithCountOptimization:    1336468

IterateForeachOnArray:                    1039196

IterateForOnArrayWithoutCountOptimization:1033318

IterateForOnArrayWithCountOptimization:   879804

@Sergey: It looks like the "int j = i;" inside the foreach loop is removed in release mode. This could explain wihy it is a little bit faster than expected.

This has been discussed to death through out the history of .NET.

On an Array, for vs. foreach is a wash.  On other types, it's basically anyone's guess, but you can expect them to be no better than the same operation on an Array.

However, as Eric Gunnerson said on this topic (blogs.msdn.com/.../115566.aspx), changing to a for loop is generally a premature optimization.  If you've got specific code that's proven to be a bottle neck, and the switch works for you, then great!  But this isn't a general optimization, and shouldn't just be applied to code under the assumption that it's universally a good idea.  There's benefits to foreach even in the cases where it's less performant, so if it's not proven to be a hot point in your code, do NOT simply switch to using for.

IEnumerable has its virtue: isolation from the type of collection and its count of items, possible execution in parallel (the next value begin prepared on a thread while the current one is handled on another), possible lower memory footprint (once items are enumerated, they can be recycled).

But of course, when dealing with optimization, arrays are often a better choice. Not only their "enumeration" using a for loop is faster, but they are also easier to use in "divide for conquer" types of parallel algorithm.

Copying data from a List<T> into an T[] can also provide some isolation from the data structure in the UI thread, while processing them in several background threads.

Pingback from  Dew Drop - November 20, 2008 | Alvin Ashcraft's Morning Dew

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #228

Hi Patrick,

Have you tried to benchmark Array.ForEach<T> and List<T>.ForEach?

I would expect the use of array.Length in the for loop to be more performant than the use of a variable. Was this a debug build?

Rico Mariani's (http://blogs.msdn.com/ricom/) advice is always to measure. Looks like that's what you did and what everyone should do. Your analysis shows that always using foreach is not always good but should not be inferred that using foreach is always bad.

Patrick for discussion:

codebetter.com/.../146343.aspx

Your idea of looking at IL is fundamentally flawed as the CLR has an optimizing JIT as well.

Cheers,

Greg

I am glad to announce that we just released a new version of NDepend where the analysis phase duration

I am glad to announce that we just released a new version of NDepend where the analysis phase duration

Pingback from  Lessons learned from a real-world focus on performance - taccato! trend tracker, cool hunting, new business ideas

Pingback from  Lessons learned from a real-world focus on performance - taccato! trend tracker, cool hunting, new business ideas

I couldn't replicate your results. For me, "for" on a list and "foreach" on a list had pretty much identical performance. (on some runs one was better, on some runs the other was better). With this code:

public class Program

{

   static int store;

   static void Main(string[] args)

   {

       var max = 100000000;

       System.Console.WriteLine("constructing");

       var xs = new System.Collections.Generic.List<int>(max);

       for (int i = 0; i < max; i++) xs.Add(i);

       System.Console.WriteLine("testing");

       for (int iloop = 1; iloop <= 2; iloop++)

       {

           System.Console.WriteLine("for");

           var length = xs.Count;

           var s = new System.Diagnostics.Stopwatch();

           s.Start();

           for (int i = 0; i < length; i++) store = xs;

           s.Stop();

           System.Console.WriteLine("for: {0}ms", s.ElapsedMilliseconds);

           s.Reset(); s.Start();

           foreach (int i in xs) store = i;

           s.Stop();

           System.Console.WriteLine("foreach: {0}ms", s.ElapsedMilliseconds);

       }

   }

}

Pingback from  Lessons learned from a real-world focus on performance - taccato! trend tracker, cool hunting, new business ideas

Pingback from  My .NET Development Links | Dev102.com

Dear patrick,

This article is more of a generalised one. The results are not always true. Here is some code which uses a View Model for a wpf tree transversal and the results are there for you to see:

Stopwatch sw = new Stopwatch();

sw.Start();

int groupCount = commandTree.Count;

for (int i = 0; i < groupCount; i++)

{

var subGroupList = commandTree.Children;

int subGroupCount = subGroupList.Count;

for (int j = 0; j < subGroupCount; j++)

{

var itemList = subGroupList[j].Children;

int itemCount = itemList.Count;

for (int k = 0; k < itemCount; k++)

{

action(itemList[k]);

}

}

}

sw.Stop();

Trace.WriteLine("Part 0 EvaluteCommandTree: " + sw.ElapsedTicks);

sw.Reset();

sw.Start();

foreach (CommandViewModel group in commandTree)

{

foreach (CommandViewModel subGroup in group.Children)

{

foreach (CommandViewModel item in subGroup.Children)

{

action(item);

}

}

}

sw.Stop();

Trace.WriteLine("Part 1 EvaluteCommandTree: " + sw.ElapsedTicks);

The result is:

Part 0 EvaluteCommandTree: 30392

Part 1 EvaluteCommandTree: 943

Atleast it shows that complex for's are slower than complex foreach's!!

BTW: I forgot to mention that I took the third iteration's time so that none of the time goes in initialisation or overheads.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Pingback from  Invalid Argument &raquo; An easy and efficient way to improve .NET code performances

In a previous post Lesson learned from a real-world focus on performance , I explained how we increased