[Numpy-discussion] extracting a random subset of a vector

Robert Kern rkern at ucsd.edu
Wed Sep 8 02:30:14 CDT 2004

Curzio Basso wrote:

> Robert Kern wrote:
>  >>>> a question about the method: isn't a bit risky to use the clock() 
> for timing the performance? The usual argument is that CPU allocates 
> time for different processes, and the allocation could vary.
>  >>>
>  >>>
>  >>> that's why I use time.clock() rather than time.time().
>  >>
>  >>
>  >>   Perhaps clearing up a mutually divergent assumption:  time.clock() 
> measures CPU time on POSIX and wallclock time (with higher precision 
> than time.time()) on Win32.
>  >
>  >
>  > FWIW, the idiom recommended by Tim Peters is the following:
>  >
>  > import time
>  > import sys
>  >
>  > if sys.platform == 'win32':
>  >     now = time.clock
>  > else:
>  >     now = time.time
>  >
>  > and then using now() to get the current time.
> Ok, now I'm really confused...
>  From the doc of the module 'time': the clock function "return the 
> current processor time as a floating point number expressed in seconds." 
> AFAIK, the processor time is not the time spent in the process calling 
> the function. Or is it? Anyway, "this is the function to use for 
> benchmarkingPython or timing algorithms.", that is, if processor time is 
> good enough, than use time.clock() and not time.time(), irregardless of 
> the system, right?

I think that the documentation is wrong.


And the relevant snippet from timeit.py:

if sys.platform == "win32":
     # On Windows, the best timer is time.clock()
     default_timer = time.clock
     # On most other platforms the best timer is time.time()
     default_timer = time.time

I will note from personal experience that on Macs, time.clock is 
especially bad for benchmarking.

Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

More information about the Numpy-discussion mailing list