Overhead of timer in application C#

Question

Hi,

How much overhead do timers cause in an application if they are running in the background continuously (regardless of the interval)?

I'm not worried about the calls that the timer will make when it ticks, but rather about the performance effects of using timers in applications where performance is of the utmost importance and am interested to hear what views there are on this.

Answer 1

The event invoked by the Timer will run in the same thread that the timer belongs to, and therefore will block that thread while performing any logic. That means that if the Timer belongs to the GUI layer, the execution of the Timer.Tick method will lock up the GUI while it's running.

To maintain performance in the main thread, i suggest using a BackgroundWorker instead that runs in it's own thread.

Answer 2

To answer in a same way: timers are invaluable for gui programming, but are pretty much useless for high performance tasks. Some issues with timers:

• they aren't regular to the millisecond (in fact in windows, nothing is) - it will fire when is its time, but when all other messages (mouse-keyboard events, control updates) are processed, because it is serialized with other messages from/to gui
• don't know .net implementation, but they wasted handles in mfc

If you are considering another thread for some operation, make sure that you don't touch any gui component from it. Use either Invoke() or copy updates for a gui to some queue, then dequeue it with timer from gui main thread.

Answer 3

The timer, between it's ticks, adds an extremely low cost to the application. It uses the OS's mechanism for schedualing (which is active regardless of your actions), as opposed to the intuitive concept of pooling the system's clock constently.

Basicly, other then the added memory and context switch addition (minor additions in this case. Shouldn't be more then adding a button to your form) there shouldn't be any more overhead.