• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 206
  • Last Modified:

Responsiveness of My.Computer.Clock.TickCount, and ways to test speed


Hey, I'm trying to speed tweak my code, and I've put a bunch of Debug.Print(My.Computer.Clock.TickCount)'s (to get a sense for which parts are slowest) in a particularly time consuminng procedure and here's a weird thing -- it seems like the My.Computer.Clock.TickCount calls themselves are slowing down the procedure -- anyone else seen that?

Aside from that, anybody have a better or slick way of trying to zero in on the time consuming parts of your code?
0
riceman0
Asked:
riceman0
  • 2
2 Solutions
 
AlexFMCommented:
The main problem of TickCount is low precision - about 20 ms. Of course, Debug.Print + time counting change execution time, but there is nothing to do with this.
For high precision time counting use StopWatch class.
0
 
SanclerCommented:
Although I agree with AlexFM about the lack of precision using Ticks, my attitude is that any case in which that degree of precision matters is not likely to be the real problem.  Users are unlikely to be bothered by nanosecond differences.

In investigating which is the slowest part of any code what matters is the relative result, not the absolute.  Yes, the actual process of timing different elements of code may affect how long that code takes to execute but, so far as I know, it does so to the same extent whatever the underlying code is.  

So I start with Tick prints at a number of points.  If those highlight major (particularly unexpected) differences in particular areas, I refine them within those areas.  If I get down to a level at which that approach does not produce meaningful results in terms of precision I then program specific test routines, looping the code in those areas a sufficient number of times to make the relative results meaningful.

But my watchword is always "does it matter?".  Nanosecond differences do matter if they are repeated enough times.  Hence the looping tests if it gets down to that level.  Otherwise ...

Roger
0
 
SanclerCommented:
After sales service ;-)

>>
Yes, the actual process of timing different elements of code may affect how long that code takes to execute but, so far as I know, it does so to the same extent whatever the underlying code is.
<<

Or perhaps not, at least with StopWatch.  See here

http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/VB_DOT_NET/Q_22047746.html

Roger
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now