foreach or List.ForEach

[Tripper]

Which is the better way to go and why?

//trivial example
List<string> strings = GetStrings();
foreach (string s in strings)
{
// some operation;
}

strings.ForEach (
delegate(string s)
{
// some operation
}
);

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] wrote:

Just add two lines, and watch the result...
..
stopwatch.Start ();
// Put the list into an array for performance
string[] sa = new string[list.Count]; <----
list.CopyTo(sa, 0); <----
Yes, but I think that counts as cheating :)
Also, try to run the first two tests only, and watch the results....

I don't see any difference there. What difference are you seeing?

Jon

[Jon Skeet [C# MVP]]

Patrik wrote:

will you blog on this so I can link it from mine?

http://msmvps.com/blogs/jon.skeet/ar...reachperf.aspx

Jon

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** *************@g 43g2000cwa.goog legroups.com...
| Willy Denoyette [MVP] wrote:
|
| > Just add two lines, and watch the result...
| > ..
| > stopwatch.Start ();
| > // Put the list into an array for performance
| > string[] sa = new string[list.Count]; <----
| > list.CopyTo(sa, 0); <----
|
| Yes, but I think that counts as cheating :)
|

Yes, a little bit ;-), but isn't that (don't keep allocating enumerators)
what ForEach is doing also?

| > Also, try to run the first two tests only, and watch the results....
|
| I don't see any difference there. What difference are you seeing?

First version: 00:00:10.590905 9 (correct? True)
Second version: 00:00:04.496689 1 (correct? True)
Third version: 00:00:04.494429 5 (correct? True)

First version: 00:00:11.449503 4 (correct? True)
Second version: 00:00:08.977291 5 (correct? True)

Willy.

[Nick Hounsome]

"Tripper" <Tr*****@discus sions.microsoft .com> wrote in message
news:8E******** *************** ***********@mic rosoft.com...

Which is the better way to go and why?

//trivial example
List<string> strings = GetStrings();
foreach (string s in strings)
{
// some operation;
}

strings.ForEach (
delegate(string s)
{
// some operation
}
);

foreach is the most readable which is way more important than any trivial
speed difference.

If you're into speed you should try:

int len - strings.Length;
for(int i = 0; i < len;++i)
sim += strings[i].Length;

I have read stuff saying that this should be fastest because it is
realtively easy to JIT compile it into entirely in-line code.

[Marc Gravell]

For a string (ar any other simple) array, yes you may be right...

However, if this was a linked-list implementation, either of the foreach /
ForEach methods is likely to outperform it due to not having to start at the
beginning each time (assuming it doesn't internally keep a cursor for
reference via the indexers).

Another issue with both the enumerator syntax and the List<T>.ForEach syntax
is that they force the caller down a particular route; this may be fine if
the varialbe is private to method, but if the variable is a *parameter* it
seems (to me at least) to use IEnumerable<T> to a: satisfy the "least
required" paradigm, and b: give the caller the most flexibility (i.e. they
can give me a list, an array, a collection, a linked-list, or whatever). And
yes, I could write an overload with the improved performance, but then I
increase my maintenance overhead.

If desired usage dictates, I might just about stretch to providing a "params
T[]" overload (which in turn calls the IEnumerable<T> version, maintaining a
single functional code-base), but I don't really want to write (and
maintain) 3 versions of the code (one for T[] using indexers, one for
List<T> using ForEach and one for IEnumerable<T> using foreach).

For me, then, foreach is still my *default* way to go (although I will make
exceptions under consideration); although not always the *absolute* best, it
is suitably performant (i.e. in the same league) without imposing any
restrictions, plus it avoids careless errors due to incorrect use (i.e.
using an indexer with a linked list).

Marc

[Marc Gravell]

And yes - I know you weren't advicating usage on a linked list;

My point is that there is a category of developer who could read this ad
think "ah, indexer usage is best" and then use it constantly. Regardless of
whether they actually have an array or just something with indexer access.
And it isn't as simple as that.

I wasn't disagreeing in principle, though.

Marc

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] wrote:

| Yes, but I think that counts as cheating :)

Yes, a little bit ;-), but isn't that (don't keep allocating enumerators)
what ForEach is doing also?
Well, there's a big difference between "copy this potentially huge
array" and "allocate a single enumerator".
| > Also, try to run the first two tests only, and watch the results....
|
| I don't see any difference there. What difference are you seeing?

First version: 00:00:10.590905 9 (correct? True)
Second version: 00:00:04.496689 1 (correct? True)
Third version: 00:00:04.494429 5 (correct? True)

First version: 00:00:11.449503 4 (correct? True)
Second version: 00:00:08.977291 5 (correct? True)

Odd. How are you compiling and running? Do you get the same difference
if you use the new benchmark as linked to from my blog entry?
(http://msmvps.com/blogs/jon.skeet/ar...reachperf.aspx)

Jon

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...
| Willy Denoyette [MVP] wrote:
| > | Yes, but I think that counts as cheating :)
| >
| > Yes, a little bit ;-), but isn't that (don't keep allocating
enumerators)
| > what ForEach is doing also?
|
| Well, there's a big difference between "copy this potentially huge
| array" and "allocate a single enumerator".
|

Not sure what you mean by that, ForEach doesn't allocate enumerators, while
foreach on the list allocates an enumerator and calls Dispose once per
iteration. 'foreach' on an array (as I did) doesn't allocate an enumerator,
it simply uses a pointer calls get_Length to get the length of the string
and advances the pointer.

| > | > Also, try to run the first two tests only, and watch the results....
| > |
| > | I don't see any difference there. What difference are you seeing?
| >
| > First version: 00:00:10.590905 9 (correct? True)
| > Second version: 00:00:04.496689 1 (correct? True)
| > Third version: 00:00:04.494429 5 (correct? True)
| >
| > First version: 00:00:11.449503 4 (correct? True)
| > Second version: 00:00:08.977291 5 (correct? True)
|
| Odd. How are you compiling and running? Do you get the same difference
| if you use the new benchmark as linked to from my blog entry?
| (http://msmvps.com/blogs/jon.skeet/ar...reachperf.aspx)
|
| Jon
|

Compiling and running from the command line with /o and /o-. Using XP SP2
and 2.0.50727.42.

There is definitely something wrong with this (First version and Second
version), the problem doesn't occur when Third follows First. More trying to
profile the "second" version alone crashes the profilers (VS2005 as well as
special profiler using the HW CPU and memory controller perfcounters). I'm
actually looking into this to see what's happening.

The new version doesn't have any of these issues, that is, they show
consistent timing and no profiler crashes !?
Here are my results running on the same box as above results.

Compiled from the cmd line with /o
Test parameters: Size=100000; Iterations=1000 0
Test 00:00:11.021892 3: LanguageForEach
Test 00:00:04.541090 5: NewDelegateEach Time
Test 00:00:04.513824 8: CachedDelegate
Test 00:00:13.687767 0: LanguageForEach WithCopy1
Test 00:00:01.678258 2: LanguageForEach WithCopy2

Same with /o-
Test parameters: Size=100000; Iterations=1000 0
Test 00:00:11.665539 3: LanguageForEach
Test 00:00:04.582094 0: NewDelegateEach Time
Test 00:00:04.545938 6: CachedDelegate
Test 00:00:14.416172 1: LanguageForEach WithCopy1
Test 00:00:02.268416 2: LanguageForEach WithCopy2

First two tests only.
Test parameters: Size=100000; Iterations=1000 0
Test 00:00:11.048661 9: LanguageForEach
Test 00:00:04.538974 6: NewDelegateEach Time

Notice the huge difference for the last test when o is turned off! The fun
of micro-benchmarks.
Willy.

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] wrote:

| Well, there's a big difference between "copy this potentially huge
| array" and "allocate a single enumerator".

Not sure what you mean by that, ForEach doesn't allocate enumerators, while
foreach on the list allocates an enumerator and calls Dispose once per
iteration.
Sorry, yes, I misread which kind of ForEach you meant. The difference
between copying it to an array and calling ForEach is that ForEach
doesn't need the extra allocation. In other words, although using array
copy / foreach is faster than using ForEach (if you copy it once and
then iterate multiple times, at least), it's clearly more expensive in
terms of memory.

<snip>
| Odd. How are you compiling and running? Do you get the same difference
| if you use the new benchmark as linked to from my blog entry?
| (http://msmvps.com/blogs/jon.skeet/ar...reachperf.aspx)

Compiling and running from the command line with /o and /o-. Using XP SP2
and 2.0.50727.42.
Interesting. I've been running with .NET 1.1. I'll try it later with
..NET 2.0 and see if that makes a difference.
There is definitely something wrong with this (First version and Second
version), the problem doesn't occur when Third follows First. More trying to
profile the "second" version alone crashes the profilers (VS2005 as well as
special profiler using the HW CPU and memory controller perfcounters). I'm
actually looking into this to see what's happening.
Goodo :)
The new version doesn't have any of these issues, that is, they show
consistent timing and no profiler crashes !?
Well, there's significantly less codependence in the new version, so
I'm not entirely surprised. It's a more realistic test in various ways.

<snip>
Notice the huge difference for the last test when o is turned off! The fun
of micro-benchmarks.

Absolutely.

Jon

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .
| Willy Denoyette [MVP] wrote:
| > | Well, there's a big difference between "copy this potentially huge
| > | array" and "allocate a single enumerator".
| >
| > Not sure what you mean by that, ForEach doesn't allocate enumerators,
while
| > foreach on the list allocates an enumerator and calls Dispose once per
| > iteration.
|
| Sorry, yes, I misread which kind of ForEach you meant. The difference
| between copying it to an array and calling ForEach is that ForEach
| doesn't need the extra allocation. In other words, although using array
| copy / foreach is faster than using ForEach (if you copy it once and
| then iterate multiple times, at least), it's clearly more expensive in
| terms of memory.
|

True, there is the memory cost. isn't making "informed and sound design
tradeoffs" the beauty of software design?

| <snip>
|
| > | Odd. How are you compiling and running? Do you get the same difference
| > | if you use the new benchmark as linked to from my blog entry?
| > |
(http://msmvps.com/blogs/jon.skeet/ar...reachperf.aspx)
| >
| > Compiling and running from the command line with /o and /o-. Using XP
SP2
| > and 2.0.50727.42.
|
| Interesting. I've been running with .NET 1.1. I'll try it later with
| .NET 2.0 and see if that makes a difference.
|

Hmmmm... generics and anon delegates on v1.1???
| > There is definitely something wrong with this (First version and Second
| > version), the problem doesn't occur when Third follows First. More
trying to
| > profile the "second" version alone crashes the profilers (VS2005 as well
as
| > special profiler using the HW CPU and memory controller perfcounters).
I'm
| > actually looking into this to see what's happening.
|
| Goodo :)
|
| > The new version doesn't have any of these issues, that is, they show
| > consistent timing and no profiler crashes !?
|
| Well, there's significantly less codependence in the new version, so
| I'm not entirely surprised. It's a more realistic test in various ways.
|

Yep, but there is more than the performance drop. The same test runs
correctly on Intel P4 and Mobile HW, but shows this pattern on 32/64 bit AMD
and Intel.

Willy.