Performance for Timer vs DispatcherTimer

Performance for Timer vs DispatcherTimer

I don't have a specific scenario in mind, but this question just crossed my mind while I was thinking of scenarios where I may want to use a Timer over a DispatcherTimer.

In the scenario where I have to perform come computationally intensive task whenever a timer event fires, and then make minor modifications to UI, would it be better in terms of performance to:

1. use a regular Timer and then use the application's Dispatcher to change the UI
2. use a DispatcherTimer (and possibly do my computationally intensive work in some async background worker if necessary).

My guess is that keeping the UI thread unblocked for as long as possible will enhance the user experience. If this is advisable, Are there any catches that I should be aware of in such a scenario?

EDIT:

I get the feeling my question was not clear enough, so I'm going to try and add a concrete, albeit made-up example.

Let's say I have to read a large file every 2 minutes, and when I'm done, I have to add an item to a ListBox. Let's say reading/processing the file takes 10-15 seconds, during which I do no UI work. What would be the best approach for something like this?

Answers & Comments...

Answer: 1

• Timer generates recurring events in an application

• DispatcherTimer is a timer that is integrated into the Dispatcher queue which is processed at a specified interval of time and at a specified priority.

Timers are not guaranteed to execute exactly when the time interval occurs, but are guaranteed not to execute before the time interval occurs. This is because DispatcherTimer operations are placed on the Dispatcher queue like other operations. When the DispatcherTimer operation executes, it is dependent of the other jobs in the queue and their priorities.

If a Timer is used in a WPF application, it is worth noting that the Timer runs on a different thread then the user interface (UI) thread. In order to access objects on the user interface (UI) thread, it is necessary to post the operation onto the Dispatcher of the user interface (UI) thread using Invoke or BeginInvoke. Reasons for using a DispatcherTimer opposed to a Timer are that the DispatcherTimer runs on the same thread as the Dispatcher and a DispatcherPriority can be set.

by : pratap khttp://stackoverflow.com/users/899271

Answer: 2

If you want to change a scalar (not a collection) value binded to UI element, you can do it not only from UI thread (e.g. from Timer delegate). And in this case you don't need to use Dispatcher.Invoke/BeginInvoke.

by : DVShhttp://stackoverflow.com/users/826213

Answer: 3

Another option is to use DispatcherTimer with creating BackgroundWorker class instance on each timer iteration. It also frees you from using Dispatcher.Invoke/BeginInvoke in many cases.

by : DVShhttp://stackoverflow.com/users/826213

Answer: 4

Main point:

to perform come computationally intensive task

This would indicate not using the DispatcherTimer. It mainly exists to perform small tasks on the main thread and avoid creating another thread.

If you use a DispatcherTimer to start a Backgroundworker you're circumventing its main purpose.

So just use a regular Timer here.

by : Henk Holtermanhttp://stackoverflow.com/users/60761

Answer: 5

After some more research and analysis, I've come to the conclusion that a regular timer works best in my made-up example. So far, I haven't had to look out for anything specific that would cause potential problems in my code. Having said that, good coding practices never hurt!

by : Kshitij Mehtahttp://stackoverflow.com/users/773885

---