If you look at the code I write, seeing a line similar to the following would be fairly common:
RaiseEvent LoadComplete(Me, New EventArgs)
Yesterday, I wouldn't have given this a second thought, but today, the story is a bit different. A friend of mine pointed me to an interesting comment by David Kean (from Microsoft) on the MSDN Wiki indicating that the line above is actually wrong!
So, based on his comment, I should be using EventArgs.Empty instead of creating a new instance, something like this:
RaiseEvent LoadComplete(Me, EventArgs.Empty)
So using EventArgs.Empty must be better somehow, so I decided to take a look and see if I could figure out just what the difference would be. The MSDN states that "The value of Empty is a read-only instance of EventArgs equivalent to the result of calling the EventArgs constructor" – so what's the difference? Time for a trip into the Reflector.
The Reflector shows two constructors:
Public Sub New()
End Sub
Shared Sub New()
EventArgs.Empty = New EventArgs
End Sub
So, EventArgs.Empty just calls New EventArgs and returns that. Right.
Anybody see something there that I'm missing? Seems to me that the somewhat more verbose, but more clear (as to what is actually happening) syntax would be better, and no less efficient. If anybody has an opinion about why you would do one instead of the other, I'd like to hear it.
If you enjoyed this article, please consider sharing it!
EventArgs.Empty does _not_ just call the constructor. It’s a static field, so that every time you reference it you are using the same object.
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).
That’s a good point Syntax, though I would have to wonder if the impact would be that significant.
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.
After discussing this topic with a few other people, the true cost of using ‘New EventArgs’ became a bit more clear. It’s a matter of scope, and a matter of garbage collection.
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.