我已经为我们工厂的控制系统编写了一个监视程序。它基本上是一个GUI，可让操作员查看闭环系统锁的当前状态，并在锁/环中断的情况下通知操作员。
现在，该操作在很大程度上取决于GUI的响应。我的前辈告诉我，他们更喜欢控制台打印，而不是使用基于TKinter的GUI，因为TKinter实时工作时会滞后。
有人可以对此方面发表评论吗？可以检查并纠正此延迟吗？
谢谢。
我想说的是，如果您的程序只是访问数据而不与数据进行交互，那么GUI似乎有些矫kill过正。众所周知，GUI是受引导的用户界面，用于通过界面引导用户。如您所指示的，如果界面只是一种状态，那么控制台程序不会出现任何问题。
但是，如果您的程序也以没有GUI的方式与数据交互，那么GUI可能是正确的选择。
您是否考虑过使用另一种编程语言的GUI？即使在控制台中，Python也有些慢。以我的经验，C ++在查看数据方面更快。祝你好运！
在tkinter程序中，您的代码属于以下四个类别之一；
mainloop之前运行的初始化代码。mainloop内部运行的回调。在第一种情况下，代码花费的时间仅影响启动时间，对于长时间运行的程序来说，启动时间可能并不那么重要。
关于第二种情况，编写良好的回调不应花费那么长时间。大约数十毫秒，可能长达100毫秒。如果花费更长的时间，它们将使GUI无法响应。因此，除非您注意到GUI缓慢（没有线程；请参阅下文），否则这应该不是问题。
这里的一个陷阱是after回调，即计划在一定时间后运行的函数。如果您太频繁]启动它们，这也会使时间的GUI饿死。
另一个可能的问题可能
是对其中包含很多项目的Canvas的操纵。就Python 3.x而言，据我所知，tkinter是线程安全的。但是，在Python的参考实现中，一次只能执行一个线程执行Python字节码
如果您的GUI使用multiprocessing在另一个进程中运行计算，除非与该另一个进程进行通信时做错了事，否则这不会大大影响GUI的速度。
太慢取决于情况。通常，不认为Python适用于hard real-time程序。要进行硬实时，还需要合适的操作系统。
那么问题就变成了系统规范中可接受的滞后是什么？不知道不可能精确回答您的问题。
似乎您的GUI只是显示某些系统状态。 前提是您不经常读取/检查数据
。如上面的回调段落中所述，可能会因过于频繁运行的回调而使GUI缺乏CPU周期。从您写的内容来看，我认为GUI的任务只是通知操作员。这使我相信任务并不是很紧迫的；需要毫秒干预时间的系统不应依赖人工。因此，根据您的信息，我会说，写有能力的GUI可能不会太慢。