Caching of DateTime.Now?

[Mark]

Hi...

We have some elapsed time stopwatches using the QueryPerformanceCounter()
win32 api, but since I was getting tired of doing the arithmatic all the time
I added some DateTime.Now.ToString("HH:mm:ss.fff")'s to the log and I noticed
an interesting quirk.

There's often about a 5ms difference between the calculations of
QueryPerformanceCounter() values and DateTime.Now and DateTime.Now is always
the one behind.

Is DateTime.Now cached for some period of time to avoid the expense of
recalculation?

Thanks
Mark

 

[Jon Skeet [C# MVP]]

We have some elapsed time stopwatches using the QueryPerformanceCounter()
win32 api, but since I was getting tired of doing the arithmatic all the time
I added some DateTime.Now.ToString("HH:mm:ss.fff")'s to the log and I noticed
an interesting quirk.

There's often about a 5ms difference between the calculations of
QueryPerformanceCounter() values and DateTime.Now and DateTime.Now is always
the one behind.

Is DateTime.Now cached for some period of time to avoid the expense of
recalculation?

It's taken from a lower frequency clock, generally.

From the docs:

<quote>
The resolution of this property depends on the system timer.
</quote>

If you're using .NET 2.0, I'd use Stopwatch rather than
QueryPerformanceCounter().

 

[Peter Duniho]

[...]
Is DateTime.Now cached for some period of time to avoid the expense of
recalculation?

No, but it does use a completely different mechanism for time reporting.

For what it's worth, you can use the Stopwatch class to implement
stopwatch functionality, getting the precision of a performance counter
without all the math.

In any case, if you're logging the data, I think you would want to ensure
that all of the logged data is using the same technique, whatever
technique you choose.

Pete

 

[Mark]

Hi Jon...

It's taken from a lower frequency clock, generally.
ah...

From the docs:

<quote>
The resolution of this property depends on the system timer.
</quote>

Yes, but that applies to QueryPerformanceCounter() too - just in different
amounts I would imagine.

If you're using .NET 2.0, I'd use Stopwatch rather than
QueryPerformanceCounter().

It's funny; before 2.0 everybody implemented StopWatch by wrapping
QueryPerformanceCounter(). I looked at the 2.0 StopWatch and the one thing I
didn't like about the api was that it just quietly shifted resolutions
depending on what was available and you had to ask "Which underlying timer
are you using?" Now, I imagine the day is long past that
QueryPerformanceCounter() isn't available (maybe on some Windows CE devices)
so the point is mostly moot.

I just kept using the StopWatch class I'd already written that looked almost
identical except that it only uses QueryPerformanceCounter().

Thanks
Mark

 

[Jeffrey Tan[MSFT]]

Hi Mark,

As I know the .Net2.0 StopWatch class actually encapsulates
QueryPerformanceCounter() API internally. So, it should meet your need.

Do you mean that you do not like the StopWatch class to use some lower
resolution timer while running some system without QueryPerformanceCounter
API? If so, you can check Stopwatch.IsHighResolution static property to
determine if the running system supports the high resolution counter. By
using this approach, you can make your decision at runtime about it.

If you encapsulates the QueryPerformanceCounter() API yourself, I think
your code will lose the portability feature of the .Net. For example, it
will fail on the platform that does not support "QueryPerformanceCounter".
So I think using StopWatch class is a better choice.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.