System Clock

J

James Harriman

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
(e-mail address removed)
 
J

Jp Calderone

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
 
T

Terry Reedy

James Harriman said:
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.
1.01412863105 # correct, seconds
-2.9333378051887848e-005

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

Now speed up a bit:-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:-2.84952814126882e-005
-1.4247640820030938e-005
which I have not figured out yet)

Terry J. Reedy
 
J

Jp Calderone

[snip]

(Oddly, I also get this:-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:
-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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top