0

Hey, I have an WPF application and using DispatcherTimer to fire an event every minute. I run my app and the cpu load jumps to 100%. I tried to compile an app without using a timer and cpu load was very low as I it expected to be.

Sample code:

DispatcherTimer MainTimer = new DispatcherTimer();
MainTimer.Tick += new EventHandler(Core.Timers.MainTimer_Tick);
MainTimer.Interval = TimeSpan.FromSeconds(60);
MainTimer.Start();

public static void MainTimer_Tick(object sender, EventArgs e)
{
 // initialize new class, do something...
}

Without that code cpu load is low. What should cause this?

Update Can I use som other timer? Accuracy isnt important.

daemon
  • 372
  • 1
  • 4
  • 24
  • Is CPU load low without code in MainTimer_Tick? – STO Jun 23 '10 at 22:05
  • You really get slow perf with an _empty_ `Tick` handler? – SLaks Jun 23 '10 at 22:12
  • I dont really know if it is slow performace. Even if there is no code in Tick, CPU load is high. – daemon Jun 23 '10 at 22:17
  • Does CPU jumps to 100% and then lowers to 0% right away or does it stay at 100% all the time? This is important, since brief 100% CPU spikes are very normal: CPU is either working or not, it can't be 50% active (unless you count 1 core out of 2 doing 100% of work). When you see 50% in task manager, it means some apps are doing something that uses CPU in very short bursts, like reading from a file, when CPU is mostly in blocked (sleeping) state waiting for a device to catch up. – repka Jun 24 '10 at 00:59
  • @repka: CPU usage is measured by the portion of a second (or other interval) that the CPU spent executing threads that were not simply waiting for events to occur. So 100% CPU usage spikes are not 'regular'; it usually means your CPU was active for an entire second. – ErikHeemskerk Jun 24 '10 at 09:38
  • @ErikHeemskerk: That's true, but I was just trying to get the point across, that sometimes it's OK to see spikes like this, as long as they are spikes, not continuous intervals. Even though your code seemingly does little, .NET might be making CPU busy by JITting your method before calling it. It might be loading referenced assemblies, invoking static constructors, etc. This shouldn't repeat itself on the following timer tick though, of course. – repka Jun 24 '10 at 11:51

1 Answers1

0

I solved this with using System.Timers.Timer. It's behaving correctly.

daemon
  • 372
  • 1
  • 4
  • 24