【问题标题】:slowly Increasing CPU load of tkinter when displaying time显示时间时缓慢增加 tkinter 的 CPU 负载
【发布时间】:2017-09-21 15:29:32
【问题描述】:

运行以下代码(修改自1

import tkinter as tk
import time
import os

class App():
    def __init__(self):
    self.root = tk.Tk()
    self.label = tk.Label(text="")
    self.label.pack()
    self.update_clock()
    self.root.mainloop()

def update_clock(self):
    now = time.strftime("%H:%M:%S")
    self.label.configure(text=now)
    print(now)
    print (os.times())
    self.root.after(1000, self.update_clock)

app=App()

随着时间的推移略微增加 CPU 负载。在下面的示例中,1 分钟内从 0.1 到 0.2

17:15:49
nt.times_result(user=0.0780005, system=**0.1092007**, children_user=0.0, children_system=0.0, elapsed=0.0)

17:16:49
nt.times_result(user=0.0780005, system=**0.2184014**, children_user=0.0, children_system=0.0, elapsed=0.0)

从长远来看,这将使一切停滞不前。

如何克服这种行为?
有没有更好的解决方案来“永远”在 tkinter 中显示时钟?

【问题讨论】:

  • 这很有趣。我也看到了同样的缓慢增长。
  • 您确定“从长远来看,这会使一切停滞不前”吗?当然,这假设 CPU 消耗呈线性增长,但很可能并非如此。
  • 真的是你的代码吗? update_clock 的缩进看起来很可疑。
  • 增加系统时间并不意味着增加cpu负载。这只是意味着系统正在代表 python 执行任务。例如,当您拨打time.strftime 时。每次调用此函数时,系统时间都会增加。

标签: python time tkinter cpu-usage can-bus


【解决方案1】:

根据documentation

os.times()

返回一个 5 元组的浮点数,表示累积(处理器或其他)时间,以秒为单位。这些项目是:用户时间,系统时间,孩子的用户时间,孩子的系统时间,以及从过去的固定点开始经过的实时时间,按此顺序。请参阅 Unix 手册页 times(2) 或相应的 Windows 平台 API 文档。在 Windows 上,只填充前两项,其他为零。

元组中的第二个浮点数是system time,根据this page system time == clock_t tms_stime

tms_stime 字段包含代表调用进程执行任务时在系统中花费的 CPU 时间。

根据系统时间上的WIKI,python 返回的值以μs 测量。 1 μs == One millionth of one second

因此,即使这些数字在增长,也不应该真正影响系统性能。

根据WIKI,windows 也可能返回1 ms100 ns 值。 1 ns == One billionth of one second1 ms = One thousandth of one second。还有数字太小而无法真正发挥作用。

更新:

经过一些测试,我可以看到每次操作的 system time 增加是因为 tkinter 小部件正在更新。我确实尝试了标签和输入字段。我确实确认为system time 显示的值是处理该方法所花费的时间。我测试了打印os.times() 只是为了看看system time 是否会与更新标签有相同的增长,但它不会。

我会继续寻找,看看我能找到什么。

我认为如果在函数的每个循环上调用相同数量的代码行,那么应该记录相同数量的处理时间。可能由于系统响应时间而略有变化,但我不应该看到此响应时间缓慢而一致地增长。

似乎只有在更新像 EntryLabelText 这样的 tkinter 小部件时才会发生这种情况。当我只是将这些值打印到控制台时,system time 永远不会上升。

【讨论】:

  • @Bryan Oakley 我对这个问题非常感兴趣,但事实证明不太可能找到有关此事的文档。你对这个问题有什么见解吗?
  • 没有记录 tkinter 小部件更新的日志或历史记录。
  • @BryanOakley 好吧,我找不到任何文档来解释os.times() 在使用after() 更新标签时报告的处理时间增加。所以我试图想出处理时间增加的可能原因。你会碰巧知道这种行为的原因吗?或者也许有一些关于os.times() 返回值的文档的链接,因为我无法找到很多关于它如何在它返回的元组的第二个浮点中读取和返回system time 的值。
  • 不要这么快就认为它是 tkinter。这很容易成为os.times() 或您对结果的解释中的问题。 Tcl/tk——tkinter 的底层技术——已被用于关键任务的 24/7 应用程序。如果有这样的问题,它会在几年或几十年前被发现。另外,您似乎声称系统时间正在增加——这是完全正常的,因为 CPU 实际上每次通过循环都在做一些事情。注意:系统时间是针对整个进程,而不是方法
  • @BryanOakley:我实际上只打印了os.times() 而没有更新小部件来测试这个。 system time 没有像更新小部件那样改变。我也测试了几个小部件。我无法在 tkinter 之外或不更新小部件时重现 system time 的增长。我不只是假设它是 tkinter,我一直在使用不同的变量进行许多测试,以尝试找到一些常见的行为或可以为我指明正确方向的东西。这就是为什么我要求您提供一些见解,因为我知道您对 tkinter 有广泛的了解。
猜你喜欢
  • 1970-01-01
  • 2020-07-24
  • 2016-06-07
  • 1970-01-01
  • 2016-12-24
  • 2021-11-03
  • 2018-01-03
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多