我有兴趣了解开发人员在为Windows平台开发高性能多线程GUI时所经历的考虑因素。我在开发交易应用程序的背景下提出这个问题，其中GUI是非常动态的，应用程序延迟是一个问题。
您看过哪些架构，或者您是否建议在MFC文档/视图中查看以在此上下文中实现观察者模式。我认为由于性能问题，不会使用文档/视图。
需要对在MFC和Qt中的单独线程中更新的UI组件/窗口进行哪些具体考虑？是否有适用于所有GUI库的一般规则？
答案 0 :(得分：9)
你正在寻找完全错误的地方。文档/视图架构的“开销”在纳秒范围内（基本上，通过指针访问数据）。
为了进行比较，您可以有意义地更新屏幕的绝对最大速率是显示器的刷新率，通常为60 Hz（即每16.67毫秒一次）。
为了使这种刷新率有意义，在任何给定的监视器更新中你都无法真正改变 - 如果你试图改变太多，用户将无法跟踪正在发生的事情。
就线程而言，到目前为止，最简单的方法是在一个线程中进行所有实际的窗口更新，并使用其他线程进行计算，从而为正在更新的窗口生成数据。只要您确保线程不需要进行大量计算等，就可以快速更新窗口非常简单。
编辑：就C ++与C＃而言，它取决于。毫无疑问，你可以从任何一个中获得完全足够的显示性能。真正的问题是你在这些显示器后面做了多少计算。您所提到的主要是显示非常接近原始数据（价格，数量等）。为此，C＃可能会很好。我的猜测是，与你交谈过的人所做的计算量远远超过了这一点 - 这就是真正的阿基里斯治愈（或者几乎任何在VM上运行的其他事情）。从我所看到的，对于非常重型的计算，C＃等并不是真正具有竞争力。
例如，在一段时间的另一个回答中，我提到了我最初在C ++中编写的应用程序，另一个团队在C＃中重新编写，其运行速度慢了约3倍。发布之后，我很好奇，并与他们进行了更多的讨论，询问他们是否无法通过一些额外的工作来提高速度，使其至少与C ++接近。
他们的回答实质上是他们已经完成了额外的工作，并且不只是“一点点”。 C＃重写花了3 1 / 2-4个月。在那段时间里，他们花了不到一个月的时间来复制原作的特征;其余的时间花在（试图）使其足够快以便可用。
我不得不提醒1）这只是一个数据点，2）我不知道你可能做的事情有多接近。尽管如此，它确实可以让您了解当您（以及如果）开始进行实际计算而不是仅仅将数据从网络传递到屏幕时可能遇到的减速类型。同时，快速查看表明它通常与Computer Language Shootout网站上的结果一致 - 但请记住Mono的结果而不是Microsoft的实现结果。
至少在我看来，真正的问题归结为：你对表现的关注是否真的有充分根据？对于90％左右的应用程序来说，重要的只是代码执行你想要的，并且执行速度很小，只要它没有得到 较慢（例如，慢几百或几千倍）。如果您的代码属于那个（大）类别，那么C＃可能是一个不错的选择。如果你确实有充分的理由担心执行速度，那么在我看来，选择C＃将是一个很多更值得怀疑。
答案 1 :(得分：3)
由于您在评论中提到了选择C ++或C＃的问题，我将推荐C＃，尤其是WPF（Windows Presentation Foundation）。从理论上讲，C ++应用程序具有比.Net应用程序更高的性能上限，因为它没有.Net框架开销来处理。但它也需要更长的时间来开发（可能）并且更容易出错和内存泄漏。
如果您要编写自己的显示控件，WPF（甚至WinForms）足够快，可以处理这种控制负载（如果与任何语言/平台一样，它是正确编写的）。此外，有大量的自定义控件可以完成这类工作（显示股票图表和诸如此类的东西），这使得构建此应用程序的速度比从头开始完成所有操作要快得多。
答案 2 :(得分：3)
我曾在交易应用程序的GUI端工作过。基本上，任何本地（即非Web）都足够快。 C ++，C＃或Java都可以。使用C ++的主要缺点是它消除了计算代码和UI之间的天然屏障。我之前的程序员有点草率，使用C ++，因此计算代码和UI有些交织在一起。这使得Qt端口变得更难。
多线程主要与UI无关。它应该在自己的线程上运行，这意味着只有计算引擎的接口需要关注在其他线程上调用的可能性。