DateTime.Now.Ticks question

A

Alain Dekker

I've written this code:

long lStart = DateTime.Now.Ticks;
....
DoLongComplexTask();
....
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.

Thanks,
Alain
 
M

Marcel Müller

Alain said:
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s" [...]
I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

Maybe your platform has only an accuracy of one second of the absolute
time. This is not that uncommon, since many platforms do not support to
set the time to factional seconds.


Marcel
 
A

Alain Dekker

Thanks for the excellent responses. After digging around a bit more I
discover that:
a) The Stopwatch class is not implemented in the Compact Framework v2 (but
is in v4)
b) Windows CE does not (usually) allow millisecond resolution from the
DateTime class. Apparently this depends on how the OEM develops the OS and
is typical.

The solution is to use Environment.TickCount which does work on Windows CE
and the CF v2.

Thanks again!
Alain


Marcel Müller said:
Alain said:
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s" [...]
I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

Maybe your platform has only an accuracy of one second of the absolute
time. This is not that uncommon, since many platforms do not support to
set the time to factional seconds.


Marcel
Click to expand...
 
A

Alfred Roth

Hello,

I also think that System.Diagnostics.Stopwatch is the best solution.
Another way is to use TimeSpan as following:

long lStart = DateTime.Now.Ticks;

DoLongComplexTask();

TimeSpan tsElapsed = new TimeSpan(DateTime.Now.Ticks - lStart);

lbDiagnostic.Text = String.Format("Time taken: {0:f3}",
tsElapsed.Milliseconds / 1000d);
 
A

Arne Vajhøj

I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

It does not claim to have 100ns accuracy. It claims to use 100ns units.

Big difference.

Arne
 
A

Arne Vajhøj

I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

http://community.opennetcf.com/arti...ond-resolution-datetime-under-windows-ce.aspx

confirms that DateTime Now Ticks has a problem on Windows CE with
milliseconds.

If I read it correct then simply using Environment.TickCount may be good
enough for your type of measuring.

Arne
 
A

Arne Vajhøj

I also think that System.Diagnostics.Stopwatch is the best solution.
Another way is to use TimeSpan as following:

long lStart = DateTime.Now.Ticks;

DoLongComplexTask();

TimeSpan tsElapsed = new TimeSpan(DateTime.Now.Ticks - lStart);

lbDiagnostic.Text = String.Format("Time taken: {0:f3}",
tsElapsed.Milliseconds / 1000d);
Click to expand...

If the problem is that DateTime.Now does not contain
millisconds info, then TimeSpan will not solve the problem.

Arne
 
A

Alain Dekker

Yes, thanks Arne. I agree with your interpretation. I've tested
Environment.TickCount and it works well. Sure, there are limitations, but
its fine for what I need!

Thanks,
Alain
 
A

Alain Dekker

Good point! I admit to having being misled by that bit of
documentation...until now! I'll be using Environment.TickCount from now on.

Thanks very much.
Alain
 
A

Arne Vajhøj

Good point! I admit to having being misled by that bit of
documentation...until now!
Click to expand...

It is a "problem" that exist in most time returning functions.

They return an integer in some unit. But the actual granularity
is significant smaller.

There is a very good point in this.

The trend for computers is to get more fine clocks over time.

If units were granularity then the unit would have to change frequently
creating a very unstable API.

By having a very small unit the API can be constant for many years.

There is also a downside. You just found it.

Arne
 
Top