9

I'm developing an Xbox 360 game with XNA. I'd really like to use C#'s yield return construct in a couple of places, but it seems to create a lot of garbage. Have a look at this code:

class ComponentPool<T> where T : DrawableGameComponent { List<T> preallocatedComponents; public IEnumerable<T> Components { get { foreach (T component in this.preallocatedComponents) { // Enabled often changes during iteration over Components // for example, it's not uncommon for bullet components to get // disabled during collision testing // sorry I didn't make that clear originally if (component.Enabled) { yield return component; } } } } ...

I use these component pools everywhere - for bullets, enemies, explosions; anything numerous and transient. I often need to loop over their contents, and I'm only ever interested in components that are active (i.e., Enabled == true), hence the behavior of the Components property.

Currently, I'm seeing as much as ~800K per second of additional garbage when using this technique. Is this avoidable? Is there another way to use yield return?

Edit: I found this question about the broader issue of how to iterate over a resource pool without creating garbage. A lot of commenters were dismissive, apparently not understanding the limitations of the Compact Framework, but this commenter was more sympathetic and suggested creating an iterator pool. That's the solution I'm going to use.

Improve this question
8
  • 1
    I doubt that yield return is the culprit. Likely the culprit is in creating the iterator. Every time you call this, an iterator is allocated. But since it's short-lived (i.e. Gen 0), it shouldn't be a problem. Are you noticing a performance problem? Commented Apr 29, 2011 at 23:00
  • Do you have to use yield return in this particular case? You should be able to write something like return preallocatedComponents.Where( c => c.Enabled );, which is cleaner and shorter. Commented Apr 29, 2011 at 23:09
  • @Danko: That works, but it causes another iterator to be created. Commented Apr 29, 2011 at 23:42
  • 1
    You can probably get rid of 1/2 of the memory allocation by changing the foreach to a for. Commented Apr 29, 2011 at 23:43
  • @Rick: You're right, it does eliminate creation of the iterators. Commented Apr 30, 2011 at 0:00

2 Answers 2

Reset to default
5

The implementation of iterators by the compiler does indeed use class objects and the use (with foreach, for example) of an iterator implemented with yield return will indeed cause memory to be allocated. In the scheme of things this is rarely a problem because either considerable work is done while iterating or considerably more memory is allocated doing other things while iterating.

In order for the memory allocated by an iterator to become a problem, your application must be data structure intensive and your algorithms must operate on objects without allocating any memory. Think of the Game of Life of something similar. Suddenly it is the iteration itself that overwhelms. And when the iteration allocates memory a tremendous amount of memory can be allocated.

If your application fits this profile (and only if) then the first rule you should follow is:

  • avoid iterators in inner loops when a simpler iteration concept is available

For example, if you have an array or list like data structure, you are already exposing an indexer property and a count property so clients can simply use a for loop instead of using foreach with your iterator. This is "easy money" to reduce GC and it doesn't make your code ugly or bloated, just a little less elegant.

The second principle you should follow is:

  • measure memory allocations to see when and where you should use with the first rule
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

4

Just for grins, try capturing the filter in a Linq query and holding onto the query instance. This might reduce memory reallocations each time the query is enumerated.

If nothing else, the statement preallocatedComponents.Where(r => r.Enabled) is a heck of a lot less code to look at to do the same thing as your yield return.

class ComponentPool<T> where T : DrawableGameComponent { List<T> preallocatedComponents; IEnumerable<T> enabledComponentsFilter; public ComponentPool() { enabledComponentsFilter = this.preallocatedComponents.Where(r => r.Enabled); } public IEnumerable<T> Components { get { return enabledComponentsFilter; } } ...
Improve this answer

3 Comments

Provided that r.Enabled doesn't change too often. If it does, you'll need some kind of dirty flag so that the component knows to rerun the query. By the way, hello, Danny. Long time.
@Jim Mischel: It does indeed change and I updated my code sample to clarify that.
@Jim: The Linq query doesn't snapshot any data - it will reiterate the original data source each time it's enumerated, so there shouldn't be any need to keep a dirty flag. If we did a .ToList() on the query, that would be a snapshot and would need to be refreshed to reflect objects whose Enabled property changed since the last .ToList(). The fact that the Linq query rescans the original data source is considered a hazard by some, but as long as you code "deliberately" you can use that behavior to your advantage. (PS Long time indeed! Say hi to Stafford for me)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.