我从Qt documentation on Performance Considerations And Suggestions得到了以下信息:
use asynchronous, event-driven programming wherever possible我不确定这是什么意思,所以我想问一下。这是否意味着我应该尽可能地使用信号/插槽(因为它们是异步的?)?
发布于 2020-03-19 09:19:50
Qt信号/时隙不一定是异步的。来自https://doc.qt.io/qt-5/threads-qobject.html
直接连接:当信号发出时,立即调用插槽。该槽在发射器的线程中执行,该线程不一定是接收器的线程。
队列连接:当控制返回到接收方线程的事件循环时,将调用插槽。该槽在接收器的线程中执行。
阻塞排队的连接:除了当前线程阻塞直到槽返回为止,对于排队的连接,槽被调用。
带有直接连接的插槽订阅的信号本质上是一个方法调用,您可以在运行时“挂钩”它。
同样,是的,你可能应该使用“异步的,事件驱动的编程”,“只要可能”,“只要可能”的合理定义。
显然,不要将对象之间的所有方法调用都替换为信号和槽。当你使用信号和槽时,不要总是让它们异步(排队)-有时你会希望订阅你的信号的对象在发射函数继续之前完成它们对你的信号的“反应”。
一般来说,当你并不关心你的信号的订阅者是否会立即或稍后调用它们的插槽时,只要连接它们而不指定连接类型,Qt就会使用Auto Connection,它会做正确的事情(线程方式)。当你关心的时候,只需指定你想要的连接类型。
如果你一开始对此感到困惑,合理的做法也可能是让所有连接在默认情况下排队--你不会真正注意到任何性能差异,这可能会防止你意外地编写依赖于“直接”执行的插槽的代码,而这并不是你的本意。
链接中的建议主要针对在主线程上生成的任何事件,很可能是由UI元素-按钮等生成的。主要思想是您希望尽快处理任何输入事件,使主线程可以接受任何后续事件并呈现您的UI,如果事件导致任何重要的工作完成,则将该工作移动到另一个线程,并让您的主线程等待完成信号,以便您的主线程保持“响应性”。如果您希望您的UI立即对任何事件做出反应,例如,通过启动“加载微调器”或显示进度条,您当然可以直接执行此操作。当然,这也适用于任何其他线程,当后台发生更大的计算时,这些线程可能需要保持响应并处理其他事件。
https://stackoverflow.com/questions/60749482
复制相似问题