Is "foreach" still bad for performance?

At Title suggest. I'm using 5.3.2f1 atm.

Also what should I look out for/avoid to optimize and increase performance in c#?

Thanks all!

 

If you're having performance problems and the profiler says it's the script with the foreach, then yes.

 

Well, regardless of what the profiler says, it's probably not a good idea to throw away valuable CPU time due to a bug in the foreach implementation. I believe it's fixed in Unity 5.5 with the compiler upgrade, though I'm unsure if this will end up in earlier versions or not.

To avoid it, don't use the foreach loop. There's never an actual need to as it's just syntactic sugar. For loops are the obvious replacement if applicable. Otherwise, you can use this approach to get the same functionality while avoiding the bug:

Code (CSharp):

1. var enumerator = collection.GetEnumerator();
2.  
3. while (enumerator.MoveNext())
4. {
5.      var element = enumerator.Current;
6.      // Loop body.
7. }

 

@JasonBricco
Is there really a bug in the for-each implementation? I though that the problem was simply that all collection types returned an object when GetEnumerator was called, causing allocation and thereby garbage. The change in 5.5, from my understanding, is that several collections will now return a struct and avoid allocation (heap allocation that is). Your code does not solve that problem, but perhaps there are more problems with for-each than I am aware of? (apart from the weird handling of clojure, which isn't really about performance)

EDIT: Actually, it seems like you are right. Calling GetEnumerator on a lot of collection-types does provide a value-type enumerator - the problem is with the implementation of for-each, which will access the enumerator through the IEnumerable<T> or IEnumerable interface, causing the return value to be boxed.

 

Worth noting that using foreach on System.Array types is fine. Also - the issue isn't that it's "bad for performance" it's that it creates extra garbage and the GC is what can tank your framerate.

 

Yes. This is a bug in the Mono implementation currently used by Unity.

 

Yep. For example foreach on List<T> should be fine. One place the real conundrum kicks in though is with a Dictionary<TKey, TValue> because it doesn't support indexing so it's necessary to use a foreach to enumerate over the values. You can use the GetEnumerator method as stated above and when calling it directly, at least on a Dictionary, will return a typed Enumerator for you and shouldn't be subject to boxing.

https://msdn.microsoft.com/en-us/library/bb346997(v=vs.110).aspx

It should be noted that the "foreach bug" doesn't exist on all collection types. I specifically mention Dictionary because it does exist there and will allocate (I believe something like 16 bytes) every time you execute the foreach loop. This probably would still hold true every time you call GetEnumerator as well, so you'd probably want to cache that enumerator as long as the contents of the dictionary aren't being changed. It's a tricky issue.

 

Linq + Lambda = Strippers & Candy = Performance Awesomeness

 

Not always the case.

 

Pretty sure this isn't the case unless it falls to the backing array's enumerator. From my understanding, the reason it works for regular arrays is because the compiler turns the foreach into a straight for loop.

 

That could be the case. I remember seeing comments previously saying that foreach on List<T> didn't allocate, but maybe it does now or maybe that comment was wrong. It was some time ago here in the forums.

 

This depends very much on what you're doing in that lambda expression. It's very easy to create a garbage monster.

 

And internally Linq is going to do the same for / foreach logic, it just wraps it in a pretty easy to use method which may build out an expression or whole expression tree as well as boxing and allocating. Linq is never, or at least in no case that I can think of, going to produce code that performs better than anything you can write yourself.

 

Rights, it's what the compiler converts it to anyways. Minus well save it some time. lol

 

Not exactly... It's still a separate method call that does the same for / foreach inside of it and there is a bit of extra overhead. So it doesn't get completely abstracted away by the compiler.

 

I picture myself under you with my mouth open ready to accept your knowledge.

 

Why do I feel the need to shower after reading that?

 

Hell, I wasn't even in the conversation and I'm going to go get a shot of penicillin just in case.

 

I just profiled three different ways to iterate over a dictionary. A standard foreach, GetEnumerator method and ElementAt method. I tested with a dictionary of gameobjects with int keys, (heh not smart use of the data structure). With 1000 and 10000 entries.
This was running under Unity 5.5 and I could find no difference in gc allocations (6.6kb for 10000) or time taken between GetEnumerator or the foreach loop.

ElementAt method was by far the worse, as ElementAt is 0(n). It also seemed to hit the gc with 400Kb allocations.
In latest version foreach is by far the fastest and tidiest method to use. Hope the details help.