Michael said:
[...]
Events are well known to be less efficient, I have read this *many* times
over the years and have accepted it long ago. If you want to disprove it
then go ahead.
I have. You just don't care to listen.
[...]
Please show me where my tests "were clearly shown to be flawed". All
you've posted is conjecture. You certainly have suggested my test was
flawed, but you've done absolutely nothing to _show_ they are flawed,
never mind do so "clearly".
I have shown they are missing the attachment of the event.
"Attachment of the event"? What does that mean? What is detached?
What needs to be attached?
All you are
testing is the speed of calling an event without even checking if exists.
So your argument is that if I add a line of code that checks for the
event being non-null, that will somehow radically change the results so
that the event is no longer faster than the virtual method?
If
you don't think that's flawed then what can I say. I suspect you've tried
these things and found the event to be less efficient so haven't posted the
results.
Heh...funny guy. I posted the code. If you believed that making that
change would have an effect, you easily could have made the change and
checked it yourself. Still, if you think it's important, I am happy to
make the change and see if it changes the outcome.
I'll be right back.
Okay, I'm back. Here's the new RunEvent() method (the only change is
the copy-to-local and check for non-null before calling the event
handler and to fix a small bug):
public long RunEvent(TimeSpan tsDuration)
{
DateTime dtEnd;
_iterations = 0;
_TestEvent += _TestEventHandler;
dtEnd = DateTime.Now + tsDuration;
while (DateTime.Now < dtEnd)
{
VoidDelegate handler = _TestEvent;
if (handler != null)
{
_TestEvent();
}
}
_TestEvent -= _TestEventHandler;
return _iterations;
}
Nope. Same outcome. There wasn't even a 1% difference in the results
as compared to the previous test. I did, by the way, figure out the
anomaly of the event-based method being twice as fast and fixed the bug
(see code above). So there's no longer the doubling in performance that
comes from having the event delegate subscribed twice.
However: the bug does illustrate that the multicast aspect of the event
is completely inconsequential to performance (the event really does get
handled twice as fast in that case, because most of the overhead is in
other stuff).
Final results: the event mechanism is still 1% to 5% faster than the
virtual method, depending on exactly what order they are done.
Maybe in some cases, but 99% of the time it makes no difference except the
efficiency.
"99%"? Again with the funny math. But even if you are going to base
your decision on efficiency (which I think is pointless in this case,
but whatever), it's the event mechanism that wins.
Pete