title: Performance cost of timers
body: <p>I need to optimize an rather big WPF application. We are getting data updates from the domain layer in a very high frequency. One idea to optimize the UI was to delay the update of some UI elements to improve the UI performance. Let's say we have a property "Counter" in the domain model that changes about 100 times per second. So we could create a timer that fires only once a second and updates an corresponding property in our ViewModel when the timer fires. That works pretty good so far. The timer would just copy the value from the domain object to the view model once a second and we're done. </p>
  
  <p>Problem is: Each view model instance represents an entry in a list. And this list could have several thousand entries. With the solution I described we would also create several thousand timers. I would guess that creating so many timer instances is no good idea. A simple solution would be to just create a static timer instance in a base class or somewhere else and just use this single instance to update all view models. But that is not possible either. We have any different properties that should be updated independently from the domain models and each should have an idividual update rate.</p>
  
  <p>Question 1: Does anyone have an idea how expensive a timer is? Does it really matter if I would create many thousand timers?</p>
  
  <p>Question 2: Another soulution would be to create some sort of scheduler ... a kind of "MultiTimer" where I can register multiple timeouts. Does anyone have an suggestion on how to implement something like that?</p>