Re: Accurate CPU timing on Windows -- How?

Michele Mazzucco wrote:

On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
  

      * On Windows [at least], System.currentTimeMillis()'s resolution
        is not milliseconds but rather about 0.01 seconds.
              * We could use System.nanoTime() instead, but it appears
                that acquiring this takes a bit more time.  Moreover,
                for the usages in question millisecond accuracy is
                sufficient, but 0.01 seconds is not always.
    

Jess,

this is a kernel issue (kernel precision is typically 10/15 ms), it's
not related with java.
  

So are you saying that System.nanoTime() is:

1. No more accurate than System.currentTimeMillis() on Windows *or*
2. Is sufficiently costly that Sun doesn't want to implement System.currentTimeMillis() via System.nanoTime()'s internals?

Clearly (b) is possible in that one can compute an offset by examining System.currentTimeMillis() and System.nanoTime() on startup, doing all timing via nanoTime() and then using the startup numbers to convert from nanoTime() results to currentTimeMillis() results.  I do it in a few places to avoid having to obtain both types of times when I already have nanoTime() for some reason.  I have to assume that (b) is more costly, though -- from my own results.

While all this is annoying the bigger issue is thread CPU time...

--
Jess Holle

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".