Re: Performance hit because of Datetime.Now
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 01 Oct 2008 12:04:14 -0700
On Wed, 01 Oct 2008 11:23:50 -0700, <chivateatul@xxxxxxxxx> wrote:
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.
Whatever the cost of retrieving DateTime.Now, it should pale in comparison to the cost of actually updating the GUI. It seems to me that if your data rate is so high that you're running into a performance issue with DateTime.Now, then one important fix you probably should make is to throttle the GUI update.
The user can only keep track of so much information at once anyway, and by throttling the GUI update, you not only eliminate whatever marginal influence the call to DateTime.Now might have, you also help ensure that the application and overal computer remains more responsive, since you don't wind up spending all your time trying to keep the UI up-to-date.
Keeping track of invalidated displayed data and updating the UI once a second, or even once every half second, would surely not in any way diminish the user experience, but would significantly improve any performance issue you're having with respect to redrawing the UI.
Note also that if all you care about is elapsed time, you may find that a better class to use is the Stopwatch class. This would be with or without improvements as described above.
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.
I still find it difficult to understand how DateTime.Now could be causing a bottleneck with respect to GUI updating. Perhaps if you could post a concise-but-complete code sample that demonstrated the problem, we could see why it is you are able to update the UI so quickly that the relatively tiny cost of calling DateTime.Now (even in the inefficient way) is dominating your performance data.
But in any case, it seems likely to me that at the very least, you can dramatically improve your performance by not issuing a redraw every single time some data shows up. Just update periodically, at a slower rate that is more in line with what a human user is capable of perceiving.
Actually my question is, has anyone idea that there is a problem with
DateTime.Now? Is it documented anywhere(MSDN???)
Even with Brian's observation that DateTime.Now takes 50x longer than DateTime.UtcNow, I remain unconvinced that there's "a problem with DateTime.Now". It may be too slow for what you're trying to do with it, but all that means is that you're not using it in an appropriate way.
Pete
.
- References:
- Performance hit because of Datetime.Now
- From: chivateatul
- Re: Performance hit because of Datetime.Now
- From: Peter Duniho
- Re: Performance hit because of Datetime.Now
- From: chivateatul
- Performance hit because of Datetime.Now
- Prev by Date: Re: Performance hit because of Datetime.Now
- Next by Date: Re: Performance hit because of Datetime.Now
- Previous by thread: Re: Performance hit because of Datetime.Now
- Next by thread: Re: Performance hit because of Datetime.Now
- Index(es):
Relevant Pages
|
