time.time or time.clock

[Ron Adam]

John Machin wrote:
> On Jan 14, 7:05 am, Ron Adam <r... at ronadam.com> wrote:
>> I'm having some cross platform issues with timing loops.  It seems
>> time.time is better for some computers/platforms and time.clock others, but
> 
> Care to explain why it seems so?
> 
>> it's not always clear which, so I came up with the following to try to
>> determine which.
>>
>>     import time
>>
>>     # Determine if time.time is better than time.clock
>>     # The one with better resolution should be lower.
>>     if time.clock() - time.clock() < time.time() - time.time():
>>         clock = time.clock
>>     else:
>>         clock = time.time
>>
>> Will this work most of the time, or is there something better?
>>
> 
> Manual:
> """
> 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.
> [snip]
> 
> 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.
> """
> 
> AFAICT that was enough indication for most people to use time.clock on
> all platforms ... before the introduction of the timeit module; have
> you considered it?

I use it to time a Visual Python loop which controls frame rate updates and 
set volocities according to time between frames, rather than frame count. 
The time between frames depends both on the desired frame rate, and the 
background load on the computer, so it isn't constant.

time.clock() isn't high enough resolution for Ubuntu, and time.time() isn't 
high enough resolution on windows.

I do use timeit for bench marking, but haven't tried using in a situation 
like this.


> It looks like your method is right sometimes by accident. func() -
> func() will give a negative answer with a high resolution timer and a
> meaningless answer with a low resolution timer, where "high" and "low"
> are relative to the time taken for the function call, so you will pick
> the high resolution one most of the time because the meaningless
> answer is ZERO (no tick, no change). Some small fraction of the time
> the low resolution timer will have a tick between the two calls and
> you will get the wrong answer (-big < -small). 

If the difference is between two high resolution timers then it will be 
good enough.  I think the time between two consectutive func() calls is 
probably low enough to rule out low resolution timers.


In the case of two
> "low" resolution timers, both will give a meaningless answer and you
> will choose arbitrarily.

In the case of two low resolution timers, it will use time.time.  In this 
case I probably need to raise an exception.  My program won't work 
correctly with a low resolution timer.

Thanks for the feed back, I will try to find something more dependable.

Ron