time.clock() vs time.time() #2844
Comments
|
Thanks for pointing this out. I have labeled the issue Easy and Enhancement. Hopefully issue labeling will help us keep track of all the issues on scikit-learn. |
|
Why not using |
The usage of timeit leads to really ugly code. In addition, we are using |
|
And in some places |
|
Hi, import time
def measure_time():
t0 = time.time()
t1 = time.time()
while t1 == t0:
t1 = time.time()
return t1-t0
def measure_clock():
t0 = time.clock()
t1 = time.clock()
while t1 == t0:
t1 = time.clock()
return t1-t0
print "time result : " + str(measure_time())
print "clock result :" + str(measure_clock()) |
|
moreover there is a huge drawback in clock(). It works ONLY within a process. Its reference is the starting of a particular process whereas the reference taken by time() is an epoch, a particular point of time in the past(fixed). We might have a problem in benchmarking multi processes with clock() |
|
I'm not sure whether your example proves anything. Also, I think |
|
hi mblondel, |
|
And by the way my code calculates the minimum time difference possible in the clock() and time() functions and returns that value. |
|
What I mean by machine with high load is a machine where several computationally expensive processes are run concurrently (e.g., a server used by several people to do ML experiments). I used to use |
It really depends on what the question that you are asking is. I |
|
Yes it depends on what question you're asking. If you want to tell whether algorithm A is faster than algorithm B, |
|
Apart from that, |
|
OK, how about we just stick with time.time()? |
|
For examples, it's not big deal to keep using Closing. |
I am not even sure that it is a good idea: as a research you might care |
|
Well some users do use scikit-learn for research purposes. The new functions introduced in PR #2759 make it possible to compare different algorithms w.r.t. to both accuracy and training time. Moreover, it is ok to use |
|
Nor am I persuaded, @mblondel. Have you found that they differ On 17 February 2014 04:25, Mathieu Blondel notifications@github.com wrote:
|
|
hi, |
So do I. The reasonning behind this is that adding too much option makes |
|
The philosophy of the project has always been to give options to the user and provide sane defaults. I really care about measuring CPU time. If I can't even use my code for my purposes, I think I'll just close PR #2759 and maintain the code privately. |
|
I think nobody wanted to provoke that. Support for multiple metrics would be a great feature. However, in other languages it is often considered to be bad practice if you have more than 3 function arguments. In Python that should not be so drastic because you have named arguments but I also think that good code should always try to find a good compromise. Before you give up on the PR we should try to find a better solution. Maybe we can postpone that to another PR? |
git grep indicates that we are using
time.time()in a few places but in generaltime.clock()is more appropriate for benchmarking:http://stackoverflow.com/questions/85451/python-time-clock-vs-time-time-accuracy
The text was updated successfully, but these errors were encountered: