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