time in milliseconds by calling time.time()

[scriptlearner]

I am trying to measure some system response time by using the time.time
() or time.clock() in my script. However, the numbers I get are in
10s of milliseconds.
For example,
1248481670.34 #from time.time()
0.08 #from time.clock()

That won't work for me, since the response time may be only a few
milliseconds.
My environment is Solaris 10 with Python 2.4.4 (#7, Feb 9 2007,
22:10:21).

SunOS 5.10 Generic_137112-07 i86pc i386 i86pc


The tricky thing is, if I run the python interpreter and import the
time module, I can get a time floating number in better precision by
calling time.time(). Do you guys have any suggestion on debugging
this problem? Or, is there any other module I can try? Thanks.

$ python
Python 2.4.4 (#7, Feb 9 2007, 22:10:21)
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.

 

[Roy Smith]

I am trying to measure some system response time by using the time.time
() or time.clock() in my script. However, the numbers I get are in
10s of milliseconds.
[...]
The tricky thing is, if I run the python interpreter and import the
time module, I can get a time floating number in better precision by
calling time.time().
[...]1248481930.8023829 <--I like this!

time.time() is returning a float in either case. The difference you are
seeing is purely related to how you are printing it; executing a "print"
statement as opposed to the interactive interpreter printing a value.

Notice:

Roy-Smiths-MacBook-Prolay$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.1248484957.151274

and further notice:
'1248485028.5814769'

Keep in mind that while a float may have a large apparent precision,
there's no promise that the actual value returned by the OS has that much
precision. You should be fine if all you're looking for is ms, but I
wouldn't count on much more than that.

 

[Andre Engels]

Keep in mind that while a float may have a large apparent precision,
there's no promise that the actual value returned by the OS has that much
precision.  You should be fine if all you're looking for is ms, but I
wouldn't count on much more than that.

Even stronger: I wouldn't count on _anything_ more than that. On my
machine, time.time() changes value once per millisecond. I tested this
by looking at a loop that recorded time.time() 100000 times. The total
time in the loop was 61 ms; out of the 100000 numbers, 61 were higher
than the previous one, with the highest difference being 1.00017 ms,
the lowest 0.999928 ms.

 

[Steven D'Aprano]

Even stronger: I wouldn't count on _anything_ more than that. On my
machine, time.time() changes value once per millisecond. I tested this
by looking at a loop that recorded time.time() 100000 times. The total
time in the loop was 61 ms; out of the 100000 numbers, 61 were higher
than the previous one, with the highest difference being 1.00017 ms, the
lowest 0.999928 ms.

I'm guessing you're running Windows, because for Windows time.time() has
a low resolution and time.clock() is the higher resolution timer.

I'm running Linux, which is the opposite:

.... deltas = []
.... for i in xrange(1, len(alist)):
.... deltas.append( alist - alist[i-1] )
.... return deltas
....

d = [time() for i in xrange(10000)] # grab raw times
dt = diffs(d) # calculate the difference between each call
max(dt), min(dt) (0.00060892105102539062, 1.9073486328125e-06)

d = [clock() for i in xrange(10000)] # and again using clock()
dc = diffs(d)
max(dc), min(dc)

(0.010000000000000009, 0.0)

More important than the maximum and minimum time deltas is the resolution
of ticks in each timer. Under Linux, clock() hardly ever gets updated:
2

while time() gets updated frequently:
9999



See also the comments in the timeit module.