Foreach, Garbage, and the CLR Profiler

re: Foreach, Garbage, and the CLR Profiler

Ultrahead — Sat, 17 Mar 2007 07:30:55 GMT

Nice read.

One question: which would be the results if you use, say, a "List<IGameEntity> entities" collection? With something like:

foreach (IGameEntity e in entities)

{

e.Update();

}

re: Foreach, Garbage, and the CLR Profiler

snprbob86 — Sat, 17 Mar 2007 08:23:28 GMT

Very interesting! Don't forget to investigate the "yield" key word :-)

re: Foreach, Garbage, and the CLR Profiler

snprbob86 — Sat, 17 Mar 2007 08:24:37 GMT

Oh, and I forgot to mention: You are missing sign-in/log-out links on your blog. Since you have annonymous comments dissabled, I had to go to another MSDN blog to log in, then come back in order to post a comment.

re: Foreach, Garbage, and the CLR Profiler

zygote — Sat, 17 Mar 2007 08:56:02 GMT

Nice article. It seems foreach() isnt as bad as people have been making it sound :)

XNA Weekly Roundup 12-03-07 to 18-03-07

Mykres Space — Sun, 18 Mar 2007 04:45:33 GMT

Here we go with another Weekly Roundup from the XNA World. 05-03-2007 Code Release George has posted

re: Foreach, Garbage, and the CLR Profiler

MichaelGiagnocavo — Sun, 18 Mar 2007 11:00:44 GMT

It's been years since I look at anything on the CLR level, but every object in the CLR requires 12 bytes for the object header (syncblock and other stuff?). This is in addition to any actual data the object has.

re: Foreach, Garbage, and the CLR Profiler

ShawnHargreaves — Mon, 19 Mar 2007 18:03:13 GMT

Yeah. The one byte array will need some extra data for CLR infrastructure. This is true for any reference type or boxed value type, but not for value types that are living on the stack.

I don't know precisely what that header contains, but if I had to guess I'd say maybe a four byte vtable pointer (which identifies the type of the object, and contains the indirection pointers for any virtual methods it may contain), plus a 4 byte array size counter, plus maybe 4 bytes for the garbage collector to tag which objects it has marked, implement write barriers and so on? (I'd guess the GC would pack quite a lot of data into an integer bitfield).

A story about premature optimization

Shawn Hargreaves Blog — Tue, 20 Mar 2007 00:09:49 GMT

Performance never ceases to be a fascinating topic. This forum thread inspired Eli to write about foreach

XNA Weekly Roundup 18-03-07 to 26-03-07

Mykres Space — Mon, 26 Mar 2007 04:31:44 GMT

Ok here we go with this weeks update… It has been a relatively quite week in the world of XNA; this must

Foreach and Garbage, Part 2

Cornflower Blue — Thu, 19 Apr 2007 04:41:14 GMT

As promised, here's a bit more about foreach and garbage. Last time I wrote about the Windows Desktop

Twin paths to garbage collector nirvana

Shawn Hargreaves Blog — Tue, 03 Jul 2007 05:14:56 GMT

In my previous post I described how to tell if your Xbox garbage collection is taking too long. We saw

re: [原创]如何改善Managed Code的Performance和Scalability系列之一：由for V.S. for each想到的

cnblogs.com — Tue, 07 Aug 2007 20:22:21 GMT

事实上对Array进行foreach的时候根本不会调用GetEnumerator()方法, 也就是被编译器给内联了. 而对于List<>, 虽然没有编译器内联GetEnumerator()

re: Foreach, Garbage, and the CLR Profiler

ShadowChaser — Wed, 04 Feb 2009 00:43:14 GMT

This blog post inspired me to dig around a bit more into the internals of List<T> and Collection<T>.

What's interesting is that all of the .NET enumerator types are structs - none are classes. What's really happening here is boxing, not allocation.

Internally, instantating a new Collection<T> "wraps" a List<T> internally. The instance is placed into a variable typed as IList<T>.

When Collection<T>.GetEnumerator() is called, a "List<T>.Enumerator" struct is returned. However, because GetEnumerator() returns IEnumerator<T>, the struct is boxed - resulting in the allocation.

Apparently the C# foreach keyword has a bit of "magic" behavior - it doesn't entirely depend on IEnumerable. If a type has a public "subtype" named "Enumerator", it instances that instead - no boxing!

Because Collection<T> wraps IList<T>, it can't provide it's own public Enumerator subtype. Foreach is forced to use the IEnumerable interface, which boxes the struct into IEnumerator<T>.

It also explains why casting List<T> to IList<T> causes the same behavior - the public Enumerator subtype is no longer 'visible' to foreach.

I ran into a problem because I wanted to expose Collections of objects as properties in my classes instead of List - mainly due to class design guidelines and the fact I wanted to "hook" into SetItem/ClearItems/RemoveItem/InsertItem. This was for my "ScreenManager.Screens" property.

On ScreenManager.Draw I was iterating over the collection, causing an allocation for each frame. I didn't want to rip out the Collection, either.

There's a nice solution. Add a normal list to the class: "List<Screen> screenList" and wrap it with the collection: "Collection<Screen> screenCollection = new Collection<Screen>(screenList)".

Iterate over the screenList in the Draw method - no allocation will be performed since it can directly access the private List<Screen> and it's Enumerator sub-struct.

The collection is directly exposed as the property, providing a clean interface for externally managing the screens.

The only gotcha here is that modifications to the underlying List<Screen> type won't call the Collection's InsertItem/SetItem/ClearItems/RemoveItem protected virtual methods.

The final pattern looks something like this:

* Create a List<T> type in a class, make it private

* Do not expose the List<T> type (keep it private)

* Create a Collection<T> type, and pass the List<T> instance to it's constructor

* Iterate using foreach (myListVariable) within the class to avoid boxing the iterator

* Do not use List<T> for modifying the list - use Collection<T> instead

* Expose Collection<T> as a public/protected property (as needed) to provide a clean interface to the collection. (see http://blogs.msdn.com/fxcop/archive/2006/04/27/585476.aspx)

Overkill for most situations, but useful in the "tight loop" game render-type code - even on the Windows platform.

re: Foreach, Garbage, and the CLR Profiler

Tiaan — Sat, 14 Feb 2009 00:22:44 GMT

@ShadowChaser: How sure are you about that "magic" behavior of the C# foreach keyword and the instantiation logic you describe for a "subtype" named "Enumerator"? I would think that the compiler can figure this out by just looking at the implementation of the GetEnumerator method of the enumerable object over which the foreach keyword needs to iterate. For example, the return type of Collection<T>.GetEnumerator is the generic IEnumerator<T> interface, which is also the case for IList<T>.GetEnumerator, while the "magic" List<T>.GetEnumerator returns List<T>.Enumerator (but this nested struct in turn also implements the generic IEnumerator<T> interface, such that List<T>.GetEnumerator is still a valid implementation of the IEnumerable<T>.GetEnumerator method). I find it hard to believe that the C# compiler would insist on you having to define a nested type called "Enumerator" for this optimization to work, but rather just insist on a specific value-type implementation of the IEnumerable<T> interface instead of just returning the basic interface itself from the enumerable's GetEnumerator method.

0.033秒的艺术 --- for vs. foreach

clayman — Sun, 17 May 2009 18:17:43 GMT

关于C#中for和foreach孰优孰劣的争论似乎从来就没有停止过，各种谣言和真相混杂在一起，似乎变成了一个很复杂的问题.....