为什么time.sleep()的准确性会受到Chrome的影响?

2024-10-02 08:28:39 发布

您现在位置:Python中文网/ 问答频道 /正文

我注意到一些奇怪的行为,可能是也可能不是我的系统特有的。(运行windows 8的联想t430)

使用此脚本:

import time

now = time.time()
while True:
    then = now
    now = time.time()
    dif = now - then
    print(dif)
    time.sleep(0.01)

我在浏览器打开时得到以下输出(我认为是名义上的)。

enter image description here

但是,如果没有打开浏览器,我会观察到严重的每循环延迟

enter image description here

显然,这与直觉背道而驰,因为我认为当您拥有更少的concurrant进程时,任何人都会期望更好的性能

对这些结果的任何见解或简单复制都将不胜感激

编辑: 有趣的是,我观察到了与此代码类似的延迟:

import time

now = time.time()

def newSleep(mark,duration):
    count = 0
    while time.time()-mark < duration:
        count+=1
    print(count)


while True:
    then = now
    now = time.time()
    dif = now - then
    print(dif)
    #time.sleep(0.01)
    newSleep(now,0.01)

虽然它确实提供了额外的见解-即一些潜在循环的实例是由于缺乏处理器可用性(通过打印计数0表示)-但我仍然注意到15毫秒的行为,其中打印计数将高达70k。。。以及10毫秒的行为,计数约为40k


Tags: importtruetimecount浏览器sleepnow计数
3条回答

我在windows和ubuntu服务器(virtualbox)(没有浏览器)上都尝试了同样的方法,但结果与我得到的平均结果相同

在Ubuntu服务器中

    0.010122537612915039
    0.010426998138427734
    0.010067939758300781
    0.010767221450805664
    0.010728120803833008
    0.010106086730957031
    0.01068258285522461
    0.010105609893798828
    0.01118612289428711
    0.010136842727661133
    0.010585784912109375
    0.010425567626953125
    0.01014852523803711
    0.010422945022583008
    0.01010894775390625

在窗户里

    0.010767221450805664
    0.010751485824584961
    0.010716915130615234
    0.010229110717773438
    0.01016545295715332
    0.010195255279541016
    0.010723352432250977
    0.010744094848632812
    0.010716438293457031
    0.010564565658569336
    0.010889291763305664
    0.010728597640991211
    0.010579824447631836
    0.010889530181884766
    0.010567903518676758
    0.010717153549194336
    0.010735273361206055

因此,在我看来,在开放的浏览器和python的性能之间没有相关性

Any insights or simple replication of these results would be appreciated.

给你:

使用您的代码和最新发布的Chrome,我可以用几乎相同的结果来确认这种行为

我测量了平均花费的时间-

正在运行的浏览器:0.01055538261329734

浏览器未运行:0.0156305539053695

我有大约30个打开的选项卡,但它们都是空闲的。目前,我想不出为什么会发生这种情况

期待进一步的见解

我额外启动了Windows7来复制你的发现,我可以证实这一点

这是一个Windows的东西,使用的定时器类型和默认分辨率为15.6毫秒(最小0.5毫秒)。应用程序可以改变当前分辨率(WinAPI函数:timeBeginPeriod),Chrome也可以这样做

This function affects a global Windows setting. Windows uses the lowest value (that is, highest resolution) requested by any process. Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. Setting a higher resolution does not improve the accuracy of the high-resolution performance counter.

2014年在Forbes杂志上发表的一篇文章涵盖了铬元素的bug,这将使分辨率永久设置为1ms,无论当前负载需要什么-这是一个问题,因为这是一个系统范围内的影响,会影响能耗。从该条中:

In an OS like Windows, events are often set to run at intervals. To save power, the processor sleeps when nothing needs attention, and wakes at predefined intervals. This interval is what Chrome adjusts in Windows, so reducing it to 1.000ms means that the system is waking far more often than at 15.625ms. In fact, at 1.000ms the processor is waking 1000 times per second. The default, of 15.625ms means the processor wakes just 64 times per second to check on events that need attention.

Microsoft itself says that tick rates of 1.000ms might increase power consumption by "as much as 25 per cent".

可以使用time.get_clock_info()从Python获得默认分辨率

namespace = time.get_clock_info('time')
namespace.adjustable
# True
namespace.implementation
# 'GetSystemTimeAsFileTime()'
namespace.monotonic
# False
namespace.resolution
# 0.015600099999999999

您可以使用ClockRes小程序从cmd获取实际分辨率

相关问题 更多 >

    热门问题