System.Windows.Forms.Timer

  • Thread starter Thread starter Davej
  • Start date Start date
So if I use the System.Windows.Forms.Timer event handler to call a
routine that might perhaps exceed the period of the timer what
precautions are necessary? Can I use System.DateTime.Now to monitor
the actual execution time? When I have tried using System.DateTime.Now
to measure the execution time of a routine I seemed to be getting some
bogus results.
Click to expand...

If interval is set to X and it takes Y to run, then it will
start every MAX(X,Y)+EPS.

I can not comment on the "bogus results" without seeing some code.

Arne
 
If interval is set to X and it takes Y to run, then it will
start every MAX(X,Y)+EPS.

I can not comment on the "bogus results" without seeing some code.

Arne
Click to expand...

Ok, so the System.Windows.Forms.Timer event handler does not create a
new thread and it does not preempt the currently executing thread (is
that the right way to say that?).


Time1 = System.DateTime.Now;
pagestr = w.DownloadLoginPage();
Time2 = System.DateTime.Now;
txtResponseTime.Text = (Time2 - Time1).ToString();

This gives me a result that looks like 00:00:00.0780000
 
Ok, so the System.Windows.Forms.Timer event handler does not create a
new thread and it does not preempt the currently executing thread (is
that the right way to say that?).


Time1 = System.DateTime.Now;
pagestr = w.DownloadLoginPage();
Time2 = System.DateTime.Now;
txtResponseTime.Text = (Time2 - Time1).ToString();

This gives me a result that looks like 00:00:00.0780000
Click to expand...

And why does 78 milliseconds seem bogus?

Arne
 
And why does 78 milliseconds seem bogus?

Arne
Click to expand...

Well, that particular value of 078 was not the issue, but my overall
uncertainty regarding whether that scheme of subtracting DateTime
values was legitimate. The range of high values I was seeing did not
seem accurate. I would see values that seemed to be off by several
seconds. It is now working better since I moved the time measurement
to surround the actual WebClient call rather than the call to the
method of the class that contained the WebClient call.
 
Well, that particular value of 078 was not the issue, but my overall
uncertainty regarding whether that scheme of subtracting DateTime
values was legitimate. The range of high values I was seeing did not
seem accurate. I would see values that seemed to be off by several
seconds. It is now working better since I moved the time measurement
to surround the actual WebClient call rather than the call to the
method of the class that contained the WebClient call.
Click to expand...

DateTime - DateTime gives a TimeSpan. That is perfectly valid.

Measuring small times on a multi tasking OS always comes with
some uncertainty.

It should not be off by seconds though. But without a code example
it is hard to say what the problem was.

Arne
 
Back
Top