The woes of boxed objects (and foreach)

The woes of boxed objects (and foreach)

• Alexandre Martins

  Any type that implements the IEnumerable interface, which is all of the collection classes.

  Basically, using foreach on an array is a special case since that's a built-in type.  In all other cases, the only way foreach can know how to iterate through the elements is by using the IEnumerable interface.

  Edit: fixed interface name... whoops.

  
  

• Al42

  By collections do you just mean Collection<T> or do you also mean all the collection types like List<T> and LinkedList<T>
  
  

• edsela

  I'm not sure I'd call it evil. I use it a lot in my own games! This is one of those balancing things: is it worth making less readable code in the interest of better performance The answer really depends on your game. If you don't have GC performance problems, it makes sense to do things in the most readable way, but if that is too slow, obviously you have to do things differently to reduce garbage.
  
  
  

• Peter McEvoy

  Exactly right - both the things you identified will create garbage.
  
  The foreach statement will create garbage because it needs to allocate an enumerator instance. If you use a disassembler to look at the code created when you do a foreach, a statement like:
  
  foreach (MyType t in myCollection)
  ...
  
  basically translates into:
  
  IEnumerator<MyType> enumerator = myCollection.GetEnumerator();
  
  while (enumerator.MoveNext())
  {
  MyType t = enumerator.Current;
  
  ...
  }
  
  For most collection types, the GetEnumerator method will have to allocate a new enumerator object, so this creates one piece of garbage per enumeration. Not a problem for things you only do a few times a frame (and I'm a big fan of foreach for the extra readability it can give) but this can be bad if you're doing it many times a frame.
  
  If you think about it, the ToLower method is always going to create garbage, because it returns a modified version of the string, so it has to allocate new memory to hold this new version.
  
  
  

• RaphaelGray

  when I compile not on the compact framework, a foreach loop through a List<ValueType> is optimized to be only local variables (stack alloc not gc):

  // types enumerator as a ValueType instead of interface to prevent boxing
  List<ValueType>.Enumerator enumerator = list.GetEnumerator();
  while (enumerator.MoveNext())
  {
    ValueType t = enumerator.Current;
    ...
  }

  You could also just use a for(;;). I don't think replacing the foreach with either of these is less readable and I personally don't think it is premature optimization. Though I do agree you should minimize upfront optimization, when you have domain knowledge of a problem I think a little upfront optimization is ok.

  
  

• beto81

  It's also worth pointing out that enumerators are only created when using foreach on collections. Using foreach on an array doesn't create an enumerator, so there is no garbage collection penalty.
  

• R.Tutus

  I like for(;;) . Foreach just throws me because it's a bit automagic for my taste.
  
  I'm a big fan of
  
  for(int i = 0; i < array.length; i++)
  
  having grown up on the VB
  
  for i = 0 to UBound(array)
  
  
  
  
  

• slyi

  I concur.  Good info and thanks for sharing.
  

• gafferuk

  Maybe the foreach statement should be removed from all samples in the XNA documentation since we've established that it's evil.
  
• The woes of boxed objects (and foreach)