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

Alain Dekker wrote:
> 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.

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

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" <(E-Mail Removed)> wrote in message
news:4e0ddfab$0$6627$(E-Mail Removed)...
> Alain Dekker wrote:
>> 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.
>
> 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

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);

On 7/1/2011 10:29 AM, Alain Dekker wrote:
> 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.

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

Big difference.

Arne

On 7/1/2011 10:29 AM, Alain Dekker wrote:
> 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.

http://community.opennetcf.com/artic...indows-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

On 7/1/2011 11:33 AM, Alfred Roth wrote:
> 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);

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

Arne

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


"Arne Vajhøj" <(E-Mail Removed)> wrote in message
news:4e0de93e$0$309$(E-Mail Removed)...
> On 7/1/2011 10:29 AM, Alain Dekker wrote:
>> 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.
>
> http://community.opennetcf.com/artic...indows-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
>

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

"Arne Vajhøj" <(E-Mail Removed)> wrote in message
news:4e0de8d1$0$309$(E-Mail Removed)...
> It does not claim to have 100ns accuracy. It claims to use 100ns units.
>
> Big difference.
>
> Arne
>

On 7/1/2011 11:41 AM, Alain Dekker wrote:
> Good point! I admit to having being misled by that bit of
> documentation...until now!

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