It's best-practice to not to create lots of short-lived temporary objects the heap as it'll eventually force a garbage collection during game-play.

It is best to create short lived value objects.

Where does this leave us with event handlers? My game object fires events quite frequently, so I don't want to create new MyThingDidSomethingEventArgs every time.

What's the alternative. What do you use?


2 Answers 2


See this document: How to: Publish Events that Conform to .NET Framework Guidelines (C# Programming Guide).

Ignore it.

There is no compelling reason to follow those guidelines when you are making a game. Make your own delegate type that takes appropriate types (either existing object references or value types):

public delegate void DidSomethingHandler(MyThing what, Vector2 where);
public event DidSomethingHandler DidSomething;

Or, if you want to be especially lazy (protip: you want to be especially lazy), you can even just do this:

public event Action<MyThing, Vector2> DidSomething;

(If creating your own delegate provides better documentation or will be used in many places, do that, otherwise just use an Action.)

Footnote: When are those event guidelines applicable? When someone else will be consuming your code - especially in versioning situations. See also: What are the benefits of having events conforming to Net guidelines?.

  • 2
    \$\begingroup\$ Small addendum, in the link in Andrew Russel's comment on my answer he posted a Shawn Hargreaves blog post, about the GC, a follow up blog post is dedicated to the GC and delegates/events: blogs.msdn.com/b/shawnhar/archive/2007/07/09/… this might be of value :) \$\endgroup\$
    – Roy T.
    Apr 2, 2011 at 21:41

You could let MyThingDidSomethingEventArgs be a struct, these are generally (not always) created on the stack instead of on the heap. However this is only viable if you include only value-types in the struct.

However more important is: what is 'quite frequently', if it's not dozens times per frame than its not going to be an issue so you shouldn't be worrying about this too soon. I understand you want to keep to best practices, but this isn't a best practice more of a optimization hint that should only be applied after you've measured that performance is impacted because of frequent garbage collection.

  • \$\begingroup\$ Actually, this is one of the cases where the "no premature optimisation" rule doesn't really apply. Obviously you don't want to sit every day with the CLR Profiler checking for allocations. But there are two strategies for dealing with the GC - one requires some up-front awareness and planning. The other hurls "no premature optimisation" out the window. \$\endgroup\$ Apr 2, 2011 at 12:29
  • \$\begingroup\$ I love Shawn Hargreaves and that is a great article (that I hadn't read before, thanks!) but I don't really know if it throws "no premature optimization" out of the window. However there is some more strategy involved in fixing this if it's a real problem. I just don't want people unnecessarily doing a lot of extra work/thinking because they might think it will become a problem, thats why I ask for the poster to first think about how much this will occur. :) \$\endgroup\$
    – Roy T.
    Apr 2, 2011 at 21:37
  • \$\begingroup\$ Oh the second strategy definitely throws it out the window - you have to use fairly bizarre programming style across your entire program, and carefully monitor your GC performance. That why I recommend the first one. The first one only affects functions in your Draw/Update loop (and, because you know this in advance, optimising it isn't really premature). And all you have to do is avoid newing reference types. Setting reference and value types with different highlight colours in Visual Studio makes this pretty easy. (Of course, this advice all only apples on 360 and WP7, not Windows.) \$\endgroup\$ Apr 3, 2011 at 4:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .