A simple benchmark demonstrates one reason why this is not the best approach:

public class EventTest
{
public EventHandler<EventArgs> MyOldStyleEvent;
public EventHandler<EventArgs> MyNewStyleEvent = delegate { };

public void DoTest()
{
Stopwatch watch = new Stopwatch();

watch.Reset();
watch.Start();
RaiseOldStyleEvent();
watch.Stop();
Console.WriteLine("Old Style No Subscribers: {0}", watch.ElapsedMilliseconds);

watch.Reset();
watch.Start();
RaiseNewStyleEvent();
watch.Stop();
Console.WriteLine("New Style No Subscribers: {0}", watch.ElapsedMilliseconds);
}

private void RaiseOldStyleEvent()
{
for (int x = 0; x < Int32.MaxValue; x++)
{
if (MyOldStyleEvent != null)
{
MyOldStyleEvent(this, EventArgs.Empty);
}
}
}

private void RaiseNewStyleEvent()
{
for (int x = 0; x < Int32.MaxValue; x++)
{
MyNewStyleEvent(this, EventArgs.Empty);
}
}
}

Output:

Old Style No Subscribers: 10631
New Style No Subscribers: 19975

I liked this idea a lot better when it ran on the front page last week. Copying someone else's post without linking to it is generally considered plagiarism, Amit.

I have never seen it here before. I am truly honest in this. really.

This is the original thread: http://www.dotnetkicks.com/events/NET_Event_Techniques

Testing the overhead when there are subscribers would probably more useful, as in most cases you implement events so somebody can subscribe to them.

Let's run this EVERY week! We can call it HUMP DAY REPOST: NEW EVENT DECLARATION PATTERN! I'll even repost my same lame comment to it: "Very nice sugar unless you rely on checking for null events to verify whether or not you have any subscribers for other behavior in your classes. The performance scenarios suggested in the comments are ridiculously unlikely. Anyone designing a framework where events with no subscribers still invoke 10k+ times in quick succession doesn't care about performance anyway, and probably won't understand the benefit of this technique in the first place ;)" <GIANT SMILEY>

Nice going jesse :)

Lets put an end to this.

I want to say to BigTuna that i am sorry, i did no mean to rip him off and i did not see his article last week. And thats it.

Amit

Do I have to do everything, myself? ;)

public class EventTest
{
public event EventHandler<EventArgs> MyOldStyleEvent;
public event EventHandler<EventArgs> MyNewStyleEvent = delegate { };

public void DoTest()
{
Stopwatch watch = new Stopwatch();

MyOldStyleEvent += new EventHandler<EventArgs>(EventTest_MyOldStyleEvent);
MyOldStyleEvent += new EventHandler<EventArgs>(EventTest_MyOldStyleEvent2);
MyNewStyleEvent += new EventHandler<EventArgs>(EventTest_MyNewStyleEvent);
MyNewStyleEvent += new EventHandler<EventArgs>(EventTest_MyNewStyleEvent2);

watch.Reset();
watch.Start();
RaiseOldStyleEvent();
watch.Stop();
Console.WriteLine("Old Style Two Subscribers: {0}", watch.ElapsedMilliseconds);

watch.Reset();
watch.Start();
RaiseNewStyleEvent();
watch.Stop();
Console.WriteLine("New Style Two Subscribers: {0}", watch.ElapsedMilliseconds);
}

void EventTest_MyOldStyleEvent(object sender, EventArgs e)
{
}

void EventTest_MyOldStyleEvent2(object sender, EventArgs e)
{
}

void EventTest_MyNewStyleEvent(object sender, EventArgs e)
{
}

void EventTest_MyNewStyleEvent2(object sender, EventArgs e)
{
}

private void RaiseOldStyleEvent()
{
for (int x = 0; x < Int32.MaxValue; x++)
{
if (MyOldStyleEvent != null)
{
MyOldStyleEvent(this, EventArgs.Empty);
}
}
}

private void RaiseNewStyleEvent()
{
for (int x = 0; x < Int32.MaxValue; x++)
{
MyNewStyleEvent(this, EventArgs.Empty);
}
}
}

Output:

Old Style Two Subscribers: 85450
New Style Two Subscribers: 111010

"Some would say that you are wasting resources but i think the Null check or an empty delegate are no big difference."

I wouldn't be so bold as to say that situations as extreme as mine are common, but it's important to mention. It's one thing to make the above claim in a blog, but it's an entirely different thing to actually prove it.

I did not claim to prove it. That was just my opinion.
And by the way if you are looking for performance you should not use .NET...

Amit - no worries, if you didn't see it then you didn't know. I thought some of your post sounded suspiciously like the comments on the original so I thought you were ripping it off. As for the performance debate, I maintain that the few wasted microseconds are worth their weight in plutonium if this avoids one late night at the office tracking down a buried null reference exception. That's the kind of performance management they don't seem to teach in school.

razamit, you stated your opinion, and from a performance viewpoint, I gave empirical data that suggested that you may have overlooked something. This should be of interest to you.

As far as your claim that you shouldn't use .NET if performance is of concern, you are again wrong in saying so. True, there are situations where unmaged C or C++ code will outperform managed C# code. However, there are also situations in which the opposite holds true. Often times, when doing benchmarks, I was amazed at the performance that could be sustained from a .NET application and often found that performance differences were negligible between unmanaged C++ and C#.

I looked over your code and although I like the general idea, I personally wouldn't use it. In my opinion, if you're going to have a new way of doing something, it should be better than the old way. To me, saving a simple "if" statement does not justify the performance hit that will be taken. If you want to use it, that's fine, but I hope that you're not using it on a high transactional system. Performance losses may be of little concern to you on your development box, but when they hit a server, they often turn up issues that require efficiency adjustments.

BigTuna - Thanks for believing me.I definitely share your opinion about long null reference nights :)

senfo - I was a bit surprised about what you said regarding the performance, so I did some checking and you are right! Very interesting.