How much performance overhead is there in using events?

is there any additional overhead to using events?

Well, yes - you have a MulitcastDelegate involved, code checking to see if an event handler is actually attached, etc.

is there significant extra overhead simply for firing off an event?

Ahh - the real question. There is overhead, but is it significant? That can only be answered by measuring it.

My guess is that any overhead you experience won't be significant (otherwise there would be warnings about using events in performance-critical applications, which I have not seen) and that there are other parts to your application that have a bigger effect on performance.

I wanted to know if there is any additional overhead to using events? I would assume that unless an event is acted upon (i.e, there is a listener in a class that executes a function based on the event being fired), then there shouldn't really be much of an impact. B

In general, this is true. The standard pattern for raising an event will do nothing but check the invocation list to see if there are subscribers, and return if there are no listeners, which will be very minor in terms of performance in most cases, and is likely not going to be an issue.

Even when there are subscribers, the overhead of using events is still fairly minor, as they are effectively calling the subscribers handlers by a delegate invocation, which is still relatively fast (though slower than a direct method call). As long as you're not doing this in very tight loops, it's likely to be insignificant.

That being said, this, like any performance question, boils down to measurement. Without actually measuring in your case, there's no way to know how significant the actual usage would be in practice. In order to know for certain whether this is a reasonable design choice in your specific case, you'd need to profile the usage of the events to make sure that it is not a significant issue.

I'm not sure if anyone has quantified the overhead, but it's probably quite small for most purposes. If you're new to programming, then you're probably not aiming to write ultra high-performance code at first (and if you were, you probably wouldn't be using C#, right?)

One thing to beware of is the scope of a published event. You can end up in a situation where there are dozens of subscribers to a given event, but really only one or two actually care about a given instance of the event. This can lead to a significant overhead. In this context, it may be worthwhile looking into the System.Observable reactive-programming paradigm. This can help limit over-broadcasting by allowing you to only invoke handlers on those subscribers that actually care about a given event.

In case anyone stumbles upon this question so many years after, I've used the BenchMarkDotNet framework to measure the time an event takes to invoke. I've made a difference between 1 subscriber and 100 subscribers.

Test code used:

private event EventHandler TestEventSingle;
private event EventHandler TestEventMultiple;

public OtherTests()
{
    TestEventSingle += OtherTests_TestEvent;

    for (int i = 0; i < 100; i++)
    {
        TestEventMultiple += OtherTests_TestEventMultiple;
    }
}

private void OtherTests_TestEventMultiple(object sender, EventArgs e)
{
    //Do something with the event...
}

private void OtherTests_TestEvent(object sender, EventArgs e)
{
    //Do something with the event...
}

[Benchmark]
public void InvokeEvent()
{
    TestEventSingle.Invoke(this, null);
}
[Benchmark]
public void InvokeEventMore()
{
    TestEventMultiple.Invoke(this, null);
}
[Benchmark]
public void CallMethod()
{
    OtherTests_TestEvent(this, null);
}
[Benchmark]
public void CallMethodMore()
{
    for (int i = 0; i < 100; i++)
    {
        OtherTests_TestEventMultiple(this, null);
    }
}

Test results: