Python time.clock () против точности time.time ()?
На всякий случай кому-то еще нужна версия F # описанного выше хака.
open System
open System.IO
open System.Net
type WebClientEx() =
inherit WebClient ()
[<DefaultValue>] val mutable m_Resp : WebResponse
override x.GetWebResponse (req: WebRequest ) =
x.m_Resp <- base.GetWebResponse(req)
(req :?> HttpWebRequest).AllowAutoRedirect <- false;
x.m_Resp
override x.GetWebResponse (req: WebRequest , ar: IAsyncResult ) =
x.m_Resp <- base.GetWebResponse(req, ar)
(req :?> HttpWebRequest).AllowAutoRedirect <- false;
x.m_Resp
member x.StatusCode with get() : HttpStatusCode =
if not (obj.ReferenceEquals (x.m_Resp, null)) && x.m_Resp.GetType() = typeof<HttpWebResponse> then
(x.m_Resp :?> HttpWebResponse).StatusCode
else
HttpStatusCode.OK
let wc = new WebClientEx()
let st = wc.OpenRead("http://www.stackoverflow.com")
let sr = new StreamReader(st)
let res = sr.ReadToEnd()
wc.StatusCode
sr.Close()
st.Close()
10 ответов
С 3,3, time.clock () удерживается от использования , и предлагается использовать время process_time () или время perf_counter () вместо этого.
Ранее в 2,7, согласно документы модуля времени :
time.clock ()
На Unix, возвратите текущее процессорное время как число с плавающей точкой, выраженное в секундах. Точность, и на самом деле самое определение значения “processor time”, зависят от той из функции C того же имени, но в любом случае, это - функция для использования для сравнительного тестирования Python или синхронизации алгоритмов.
В Windows, эта функция возвращается, тактовые стеной секунды протекли начиная с первого вызова к этой функции, как число с плавающей точкой, на основе функции Win32 QueryPerformanceCounter (). Разрешение обычно лучше, чем одна микросекунда.
Кроме того, существует модуль timeit для сравнительного тестирования фрагментов кода.
-
1я don' t сделали, чтобы разработчик считал, отлаживаю мои приложения на средстве моделирования. спасибо!! – sanjay 28 October 2013 в 03:10
Короткий ответ: используйте time.clock () для синхронизации в Python.
На *отклоняют системы, часы () возвращают процессорное время как число с плавающей точкой, выраженное в секундах. В Windows это возвращается, секунды протекли начиная с первого вызова к этой функции как число с плавающей точкой.
время () возвращает секунды с эпохи, в UTC, как число с плавающей точкой. Нет никакой гарантии, что Вы получите лучшую точность, что 1 секунда (даже при том, что время () возвращает число с плавающей точкой). Также обратите внимание, что, если системные часы были задержаны между двумя вызовами к этой функции, второй вызов функции возвратит нижнее значение.
clock()-> Возврат числа с плавающей точкой
процессорное время или реальное время начиная с запуска процесса или начиная с первого вызова к clock(). Это имеет столько же точности сколько системные записи.
time()-> Возврат числа с плавающей точкой
текущее время в секундах с Эпохи. Части секунды могут присутствовать, если системные часы обеспечивают их.
Обычно time() более точно, потому что операционные системы не снабжают время выполнения процесса точностью, они хранят системное время (т.е., фактическое время)
В меру моего понимания, time.clock () имеет столько точности, сколько Ваша система позволит его.
На Unix time.clock () измеряет сумму процессорного времени, которое использовалось текущим процессом, таким образом, это бесполезно для измерения прошедшего времени от некоторой точки в прошлом. В Windows это будет иметь размеры, тактовые стеной секунды протекли начиная с первого вызова к функции. В любой системе time.time () возвратится, секунды передали с эпохи.
, Если Вы пишете код, это означало только для Windows, любой будет работать (хотя Вы будете использовать два по-другому - никакое вычитание не необходимо для time.clock ()). Если это соберется работать на системе Unix, или Вы хотите код, который, как гарантируют, будет портативным, Вы захотите использовать time.time ().
Короткий ответ: большую часть времени time.clock() будет лучше. Однако при синхронизации некоторых аппаратных средств (например, некоторый алгоритм, Вы вставляете GPU), тогда time.clock() избавится от этого времени, и time.time() единственное оставленное решение.
Примечание: безотносительно используемого метода синхронизация будет зависеть от факторов, которыми Вы не можете управлять (когда будет процесс переключаться, как часто...), это хуже с time.time(), но существует также с time.clock(), таким образом, Вы никогда не должны запускать один тест синхронизации только, но всегда выполнять серию теста и взгляда на средний / различие времен.
Другие ответили на ре: time.time() по сравнению с time.clock().
Однако при синхронизации выполнения блока кода для сравнительного тестирования/профилирования целей необходимо смотреть на timeit модуль .
Зависит от того, о чем Вы заботитесь. Если Вы подразумеваете, что СТЕННОЕ ВРЕМЯ (как в, время на часах на Вашей стене), time.clock () не обеспечивают точности, потому что это может управлять процессорным временем.
Различие является очень определенным для платформы.
часы () очень отличаются в Windows, чем на Linux, например.
Для вида примеров Вы описываете, Вы, вероятно, хотите "timeit" модуль вместо этого.
Следует помнить об одном:
изменение системного времени влияет на time.time () , но не на time.clock () .
Мне нужно было контролировать выполнение некоторых автоматических тестов. Если один шаг тестового примера занял больше заданного времени, этот TC был прерван, чтобы перейти к следующему.
Но иногда необходимо было изменить системное время (чтобы проверить модуль планировщика тестируемого приложения), поэтому после установки системного времени через несколько часов в будущем тайм-аут TC истек, и тестовый пример был прерван. Мне пришлось переключиться с time.time () на time.clock () , чтобы справиться с этим должным образом.