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:
>      a. No more accurate than System.currentTimeMillis() on Windows
>         *or*
>      b. 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
>