«

Hi,

I need to be able to measure a time interval in milliseconds on a windows
machine. I have tried using time.clock() but it appears to measure time in
seconds...Is there a way to measure time more precisely?

Regards,

James Harriman

On Fri, Nov 07, 2003 at 12:40:37AM +0000, James Harriman wrote:
> Hi,
>
> I need to be able to measure a time interval in milliseconds on a windows
> machine. I have tried using time.clock() but it appears to measure time in
> seconds...Is there a way to measure time more precisely?

From http://www.python.org/doc/lib/module-time.html

clock()
On Unix, return the current processor time as a floating point number
expressed in seconds. The precision, and in fact the very definition of the
meaning of `processor time'' , depends on that of the C function of the same
name, but in any case, this is the function to use for benchmarking Python
or timing algorithms.

On Windows, this function returns wall-clock seconds elapsed since the
first call to this function, as a floating point number, based on the Win32
function QueryPerformanceCounter(). The resolution is typically better than
one microsecond.

time()
Return the time as a floating point number expressed in seconds since
the epoch, in UTC. Note that even though the time is always returned as a
floating point number, not all systems provide time with a better precision
than 1 second. While this function normally returns non-decreasing values,
it can return a lower value than a previous call if the system clock has
been set back between the two calls.

Jp

"James Harriman" <> wrote in message
news:9SBqb.8942$...
> Hi,
>
> I need to be able to measure a time interval in milliseconds on a
windows
> machine. I have tried using time.clock() but it appears to measure
time in
> seconds...Is there a way to measure time more precisely?

For floats, what matters is the resolution (precision), not the unit.
On AMDK2-385, Win 98:

>>> a=time.clock(); time.sleep(1); print time.clock()-a
1.01412863105 # correct, seconds

>>> time.clock()-time.clock()
-3.0171474548978949e-005
>>> time.clock()-time.clock()
-3.1847667571582861e-005
>>> time.clock()-time.clock()
-3.100957104607005e-005
>>> time.clock()-time.clock()
-2.933337799504443e-005
>>> time.clock()-time.clock()
-3.0171474577400659e-005
>>> time.clock()-time.clock()
-3.100957104607005e-005
>>> time.clock()-time.clock()
-3.1009571102913469e-005
>>> time.clock()-time.clock()
-2.9333378051887848e-005

This is reproducibly .03+ milleseconds (minus because earlier - later)
== 30 microseconds.

Now speed up a bit:
>>> tc = time.clock
>>> tc()-tc()
-2.8495281526375038e-005
>>> tc()-tc()
-2.7657185000862228e-005
>>> tc()-tc()
-3.017147452055724e-005
>>> tc()-tc()
-2.6819088532192836e-005
>>> tc()-tc()
-2.8495281526375038e-005
>>> tc()-tc()
-2.7657185000862228e-005
>>> tc()-tc()
-2.8495281526375038e-005
>>> tc()-tc()
-2.7657185000862228e-005
>>> tc()-tc()
-2.7657185000862228e-005

The average is about 28 microsecs, so time.clock lookup appears to be
measurebly about 1 microsecond, but anything much smaller would be
lost in the noise on this system.

(Oddly, I also get this:
>>> tc()-tc(); tc()-tc()
-2.84952814126882e-005
-1.4247640820030938e-005
which I have not figured out yet)

Terry J. Reedy

On Thu, Nov 06, 2003 at 10:47:19PM -0500, Terry Reedy wrote:
>
> [snip]
>
> (Oddly, I also get this:
> >>> tc()-tc(); tc()-tc()
> -2.84952814126882e-005
> -1.4247640820030938e-005
> which I have not figured out yet)
>

I think this indicates there is more than one cost path down into the timing
machinery. Consider:

>>> time()-time();time()-time();time()-time();time()-time();time()-time();time()-time();time()-time();time()-time();time()-time();time()-time()
-3.9339065551757812e-06
-9.5367431640625e-07
0.0
-1.0728836059570312e-06
-1.0728836059570312e-06
-1.0728836059570312e-06
-9.5367431640625e-07
-9.5367431640625e-07
0.0
0.0

It appears to me as though making subsequent calls to time.time() in rapid
succession allows one to exploit an optimization somewhere.

Perhaps some hardware-level caching?

Jp