La précision time.clock () de Python par rapport à time.time ()?
Quel est le meilleur à utiliser pour le chronométrage en Python? time.clock () ou time.time ()? Lequel fournit plus de précision?
par exemple:
start = time.clock()
... do something
elapsed = (time.clock() - start)
vs.
start = time.time()
... do something
elapsed = (time.time() - start)
À partir de 3.3, time.clock () est obsolète , et il est suggéré d'utiliser time .process_time () ou time.perf_counter () à la place.
Précédemment dans 2.7, selon le documentation du module de temps:
time.clock ()
Sous Unix, renvoyez le temps processeur actuel sous forme de nombre à virgule flottante exprimé en secondes. La précision, et en fait la définition même du sens de "temps processeur", dépend de celle de la fonction C du même nom, mais dans tous les cas, , il s’agit de la fonction à utiliser pour le benchmarking Python ou les algorithmes de synchronisation.
Sous Windows, cette fonction renvoie le nombre de secondes écoulées depuis le premier appel de cette fonction sous forme de nombre à virgule flottante, basé sur la fonction Win32 QueryPerformanceCounter (). La résolution est généralement meilleure qu'une microseconde.
De plus, il existe le module timeit pour l'analyse comparative des extraits de code.
La réponse courte est: la plupart du temps, time.clock() sera meilleur. Cependant, si vous chronométrez du matériel (par exemple, un algorithme que vous avez mis dans le GPU), alors time.clock() se débarrassera de cette heure et time.time() est la seule solution qui reste.
Remarque: quelle que soit la méthode utilisée, le timing dépend de facteurs que vous ne pouvez pas contrôler (quand le processus changera-t-il, combien de fois, ...), ceci est pire avec time.time() mais existe aussi avec time.clock(), vous ne devriez donc jamais exécuter un seul test de chronométrage, mais toujours effectuer une série de tests et examiner la moyenne/la variance des temps.
Une chose à garder à l'esprit: Changer l'heure du système affecte time.time() mais pas time.clock().
Je devais contrôler certaines exécutions de tests automatiques. Si une étape de la procédure de test prend plus de temps, le TC est abandonné pour passer à l'étape suivante.
Cependant, il est parfois nécessaire de modifier l'heure du système (pour vérifier le module de planification de l'application testée). Ainsi, après avoir défini l'heure système quelques heures plus tard, le délai d'attente TC a expiré et le scénario de test a été abandonné. Je devais passer de time.time() à time.clock() pour gérer cela correctement.
clock() -> nombre en virgule flottante
Renvoie le temps CPU ou le temps réel depuis le début du processus ou depuis le premier appel à clock(). Cela a autant de précision que le système enregistre.
time() -> nombre en virgule flottante
Renvoie l'heure actuelle en secondes depuis l'époque. Des fractions de seconde peuvent être présentes si l'horloge système les fournit.
Habituellement, time() est plus précis, car les systèmes d'exploitation ne stockent pas l'heure d'exécution du processus avec la précision dont ils stockent l'heure système (c'est-à-dire l'heure réelle).
Cela dépend de ce qui compte pour vous. Si vous voulez parler de l'heure du mur (time in), time.clock () n'offre aucune précision, car il peut gérer le temps processeur.
Pour ma propre practice. time() a une meilleure précision que clock() sous Linux. clock() a seulement une précision inférieure à 10 ms. Alors que time() donne la précision du préfet. Mon test est sur CentOS 6.4 ， python 2.6
using time():
1 requests, response time: 14.1749382019 ms
2 requests, response time: 8.01301002502 ms
3 requests, response time: 8.01491737366 ms
4 requests, response time: 8.41021537781 ms
5 requests, response time: 8.38804244995 ms
using clock():
1 requests, response time: 10.0 ms
2 requests, response time: 0.0 ms
3 requests, response time: 0.0 ms
4 requests, response time: 10.0 ms
5 requests, response time: 0.0 ms
6 requests, response time: 0.0 ms
7 requests, response time: 0.0 ms
8 requests, response time: 0.0 ms
La différence est très spécifique à la plate-forme.
clock () est très différent sous Windows que sous Linux, par exemple.
Pour le type d’exemples que vous décrivez, vous préférez probablement le module "timeit".
Sous Unix, time.clock () mesure la quantité de temps CPU utilisée par le processus en cours. Il n'est donc pas bon de mesurer le temps écoulé à un moment donné. Sous Windows, il mesurera les secondes de l'horloge murale écoulées depuis le premier appel à la fonction. Quel que soit le système, time.time () renvoie les secondes écoulées depuis l’époque.
Si vous écrivez du code destiné uniquement à Windows, l’un ou l’autre fonctionnera (bien que vous utilisiez les deux de manière différente, aucune soustraction n’est nécessaire pour time.clock ()). Si cela doit fonctionner sur un système Unix ou si vous voulez que le code soit portable, vous voudrez utiliser time.time ().
Comme d'autres l'ont noté, time.clock() est obsolète en faveur de time.perf_counter() ou time.process_time(), mais Python 3.7 introduit un délai de résolution en nanosecondes avec time.perf_counter_ns() , time.process_time_ns() , et time.time_ns() , avec 3 autres fonctions.
Ces 6 nouvelles fonctions de résolution en nansecondes sont détaillées dans PEP 564 :
time.clock_gettime_ns(clock_id)
time.clock_settime_ns(clock_id, time:int)
time.monotonic_ns()
time.perf_counter_ns()
time.process_time_ns()
time.time_ns()Ces fonctions sont similaires à la version sans le suffixe _ns, mais renvoient un nombre de nanosecondes sous la forme d'un Python int.
Comme d'autres l'ont également noté, utilisez le module timeit pour chronométrer des fonctions et de petits extraits de code.
Réponse courte: utilisez time.clock () pour chronométrer en Python.
Avec les systèmes * nix, clock () renvoie le temps de traitement sous forme de nombre à virgule flottante, exprimé en secondes. Sous Windows, le nombre de secondes écoulées depuis le premier appel à cette fonction est renvoyé sous forme de nombre à virgule flottante.
time () renvoie les secondes depuis l’époque, en UTC, sous forme de nombre à virgule flottante. Rien ne garantit que vous obtiendrez une précision supérieure à 1 seconde (même si time () renvoie un nombre à virgule flottante). Notez également que si l'horloge système a été remise entre deux appels à cette fonction, le second appel de fonction retournera une valeur inférieure.
J'utilise ce code pour comparer 2 méthodes. Mon système d'exploitation est Windows 8, Core i5, RAM 4GB
import time
def t_time():
start=time.time()
time.sleep(0.1)
return (time.time()-start)
def t_clock():
start=time.clock()
time.sleep(0.1)
return (time.clock()-start)
counter_time=0
counter_clock=0
for i in range(1,100):
counter_time += t_time()
for i in range(1,100):
counter_clock += t_clock()
print "time() =",counter_time/100
print "clock() =",counter_clock/100
sortie:
time () = 0.0993799996376
clock () = 0.0993572257367
Autant que je sache, time.clock () a autant de précision que votre système le lui permettra.
Bonne réponse: Ils ont la même longueur d’une fraction.
Mais lequel plus rapidement si subject est time?
n petit cas de test:
import timeit
import time
clock_list = []
time_list = []
test1 = """
def test(v=time.clock()):
s = time.clock() - v
"""
test2 = """
def test(v=time.time()):
s = time.time() - v
"""
def test_it(Range) :
for i in range(Range) :
clk = timeit.timeit(test1, number=10000)
clock_list.append(clk)
tml = timeit.timeit(test2, number=10000)
time_list.append(tml)
test_it(100)
print "Clock Min: %f Max: %f Average: %f" %(min(clock_list), max(clock_list), sum(clock_list)/float(len(clock_list)))
print "Time Min: %f Max: %f Average: %f" %(min(time_list), max(time_list), sum(time_list)/float(len(time_list)))
Je ne travaille pas dans un laboratoire suisse, mais j'ai déjà testé.
Basé sur cette question: time.clock() est meilleur que time.time()
Edit: time.clock() est un compteur interne, donc vous ne pouvez pas utiliser à l'extérieur, avec les limitations max 32BIT FLOAT, vous ne pouvez pas continuer à compter si vous ne stockez pas la première/la dernière valeur. Impossible de fusionner un autre compteur ...