What is the theoretical speed limit for repeated firing of events in C#? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I'm about to begin a project where realtime data transmission and visualization is a core feature. Streams of numeric values will be received via USB and plotted on the screen. Most probably some kind of DataReceived(some_data) event will be listened to.

So I am interested to know the theoretical limits of event-firing in C#, so that I can know beforehand if an impossible bottleneck is being "disigned" that will later require substantial change or more severe problems.

These are some example situations:

1. If I tell an object to run an infinite loop that does nothing but fire an event, what would be the firing frequency?
2. If I circularly chain similar objects so that object B listens to A.Fired, C listens to B.Fired, etc. and A listens to N.fired, how many time would be elapsed for a full turn? How does event chaining works in general? Are they typically costly or typically lightweight or what?
3. How does data passing via arguments impacts event frequency performance.

As a bonus question: is there a "design pattern" for realtime, multithreaded data acquisition in C#?

Answer 1

C# events are dispatched on the same thread they are raised from, so it will be as fast as your computer can run it. There is no scheduler work at play, no waking up threads. The frequency question can't be answered accurately without testing it on your machine, and it does scale with your machine. The time spent raising events will be insignificant compared to the time you'll spend processing them.

Passing arguments to events is about the same as passing arguments to function calls, and the JIT decides the low-level calling convention. The worst-case scenario would be that each argument is passed on the stack.

If your design needs to be multithreaded, you'll need to pay attention to scheduler details and inter-thread communication much more than to events performance.

Finally, it strikes me as odd to me to use C# and be concerned with such low-level details. The definition of a real-time system is a system in which response time is guaranteed, and C# being garbage-collected, you can't make very strong guarantees about response time. If you're so worried about the cost of passing arguments to functions, I'd argue that you should look towards other languages in which you can actually control these details.