Since a new instance would fall out of scope when the method call ends (and thus make its way to the GC), and EventAgrs.Empty will remain in memory (as it wont fall out of scope). That explains a large part of the expense involved.

So with that fact in mind, I can see where using EventArgs.Empty could have a more significant impact. With as often as events are called and the number of otherwise useless EventArgs that could end up in memory, yeah, EventArgs.Empty is the way to go.

Most instances of EventArgs are fairly short-lived, they will only be in memory for a relatively short amount of time. Unless the code uses a rather large number of events, seems to me the impact either way will be fairly small.

For certain architectures though I can see that it may be a more significant impact, a proper implementation of MVC tends to be quite heavy when it comes to event code. In those situations, I guess I could see it possibly being more significant.

I may have to do some testing, figure out just how expensive the call really is.

This has the advantage that you are saving an object creation every time it is used. With event heavy code, this can be a large win.

(Of course, the _real_ solution to this is to have the compiler identify that the object will never be changed from the default state, and handle this optimisation transparently. I’m not sure this analysis is actually tractable in general, however).