Peter Duniho
10/1/2008 7:04:00 PM
On Wed, 01 Oct 2008 11:23:50 -0700, <chivateatul@gmail.com> 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