Performance hit because of Datetime.Now

[chivateatul]

If DateTime.Now is called in a very large loop, it's a time consuming
& also CPU utilization increases.
Instead, getting current datetime by following way is much more
efficient.

So is there any performance issue with DateTime.Now? is this a correct
way to get current datetime?

Pseudo Code:
- - - - - - - - - - -
static DateTime dateTime = DateTime.Now;
static int StartTicks = Environment.TickCount;

public DateTime CurrentDateTime
{
get
{
return dateTime.AddMilliseconds(Environment.TickCount -
StartTicks);
}
}

 

[Brian Gideon]

If DateTime.Now is called in a very large loop, it's a time consuming
& also CPU utilization increases.
Instead, getting current datetime by following way is much more
efficient.

So is there any performance issue with DateTime.Now? is this a correct
way to get current datetime?

Pseudo Code:
- - - - - - - - - - -
static DateTime dateTime = DateTime.Now;
static int StartTicks = Environment.TickCount;

public DateTime CurrentDateTime
{
   get
   {
       return dateTime.AddMilliseconds(Environment.TickCount -
StartTicks);
   }



}

DateTime.Now actually calls DateTime.UtcNow and then converts the
result to the local time zone. I did a quick test and observed that
UtcNow is about 50x faster.

 

[chivateatul]

DateTime.Now actually calls DateTime.UtcNow and then converts the
result to the local time zone.  I did a quick test and observed that
UtcNow is about 50x faster.- Hide quoted text -

- Show quoted text -

Thanx Brian,

But from Reflector, DateTime.Now calls GetSystemFileTime() & with
Datetime.UtcNow calls 'Win32Native.GetSystemTimeAsFileTime(ref
lpSystemTimeAsFileTime)'

So to get current datetime in a efficiently, which is the best way?

 

[chivateatul]

If you are calling DateTime.Now so often that it's a performance issue,  
then you probably should fix the underlying design so that you don't call 
it so often.

It's hard to know for sure what the best approach would be without knowing  
more about why you're calling it.  But it just doesn't seem to me that a  
call to DateTime.Now should represent a significant part of your  
processing, even as slow as it is.

Pete

Thanx Pete,

Actually I am writing a gui in winform, which handles live data, &
that data is displayed in a grid(3rd party grid), in which when any
cell has to paint it raises event for each cell & in that event
depending on our business logic, we need to take datetime.now & the
previous datetime.Now, to know the timedifference between earlier
event call & current event call for that cell & since live data
updates are at a high rate this event gets fired continuously. Overall
gui is in a good shape to handle that data, but we are further
optimizing it at all levels, and there we find out problem with
DateTime.Now.

Actually my question is, has anyone idea that there is a problem with
DateTime.Now? Is it documented anywhere(MSDN???)

 

[Brian Gideon]

Thanx Brian,

But from Reflector, DateTime.Now calls GetSystemFileTime() & with
Datetime.UtcNow calls 'Win32Native.GetSystemTimeAsFileTime(ref
lpSystemTimeAsFileTime)'

So to get current datetime in a efficiently, which is the best way?

When I use Reflector I'm seeing that DateTime.Now calls UtcNow and
ToLocalTime. Based on the test I did UtcNow is significantly faster
probably because it doesn't have the extra step of calling
ToLocalTime. Getting in the habit of doing all time processing in UTC
is a good practice anyway. Convert to the local time zone only when
displaying the time to a user.

 

[Brian Gideon]

Actually I am writing a gui in winform, which handles live data, &
that data is displayed in a grid(3rd party grid), in which when any
cell has to paint it raises event for each cell & in that event
depending on our business logic, we need to take datetime.now & the
previous datetime.Now, to know the timedifference between earlier
event call & current event call for that cell & since live data
updates are at a high rate this event gets fired continuously. Overall
gui is in a good shape to handle that data, but we are further
optimizing it at all levels, and there we find out problem with
DateTime.Now.

Like Peter I'm having hard believe that DateTime.Now is the dominating
factor with the performance issue you're seeing. Unless of course you
call it repeatedly in a tight loop. If that's case then cache the
result of DateTime.Now in a local variable before the loop starts.

Actually my question is, has anyone idea that there is a problem with
DateTime.Now? Is it documented anywhere(MSDN???)

I don't think there is a problem. It's slow because ToLocalTime is
also slow. Just take a look at what it's doing via Reflector.

 

[chivateatul]

Like Peter I'm having hard believe that DateTime.Now is the dominating
factor with the performance issue you're seeing.  Unless of course you
call it repeatedly in a tight loop.  If that's case then cache the
result of DateTime.Now in a local variable before the loop starts.


I don't think there is a problem.  It's slow because ToLocalTime is
also slow.  Just take a look at what it's doing via Reflector.

Thanx guys,

I got result. In my code instead of dateTime.Now, I started using
Datetime.UtcNow as suggested by Brian.

Datetime.Now is not a bottleneck, but because of nature of the
requirenment, its getting called multiple times, and we were not
expecting that datetime.Now will be slow or Datetime.UtcNow will be
further faster than datetime.Now.
We know Datetime.Now is not a bottleneck in the gui, or as I mentioned
our gui is handling all tghose updates very efficiently but for
further improvement, there are many small things and each contribute
little penny and now we have to clear all those little things , and
in that context datetime.Now is one thing

And as I mentioned, We were not expecting slowness from Datetime.Now,
but compared to Datetime.UtcNow its slow (if tested in a tight loop),
so I was just curious if there is any technical stuff that says
Datetime.Now is little slower than XXX method because of ......
But any way, for my project I got solution. Thanx