c++ - VC++/C++ 高性能多线程GUI交易注意事项

标签 c++ windows multithreading qt mfc

我很想知道有经验的开发人员在为 Windows 平台开发高性能多线程 GUI 时会考虑哪些因素。我在开发交易应用程序的背景下提出这个问题,其中 GUI 非常动态并且应用程序延迟是一个问题。

您见过哪些架构,或者您会推荐查看 MFC 文档/ View 以在此上下文中实现观察者模式。我相信由于性能问题不会使用文档/ View 。

在 MFC 和 Qt 中,对于在单独线程中更新的 UI 组件/窗口,需要特别注意什么?是否有适用于所有 GUI 库的通用规则?

最佳答案

您正在寻找完全错误的地方。文档/ View 架构的“开销”在纳秒范围内(基本上,通过指针访问数据)。

为了比较,您可以有意义地更新屏幕的绝对最大速率是显示器的刷新率,通常为 60 Hz(即每 16.67 毫秒一次)。

为了使这种刷新率有意义,您不能在任何给定的监视器更新中真正改变太多——如果您尝试改变太多,用户将无法了解正在发生的事情。

就线程而言,到目前为止,最简单的方法是在一个线程中完成所有实际的窗口更新,并使用其他线程进行计算,以便为正在更新的窗口生成数据。只要您确保线程不需要进行大量计算等操作,就可以很容易地尽可能快地更新窗口。

编辑:就 C++ 与 C# 而言,这要视情况而定。我毫不怀疑您可以从任何一个中获得完全足够的显示性能。真正的问题是您在这些显示器后面进行了多少计算。您提到的内容主要显示非常接近原始数据(价格、数量等)。为此,C# 可能会很好。我的猜测是,与您交谈过的人正在做比这多得多的计算——这就是 .NET(或几乎任何在 VM 上运行的几乎任何其他东西)真正的致命弱点。据我所知,对于真正繁重的计算,C# 等并不是很有竞争力。

举个例子,前一段时间我在另一个回答中提到了一个我最初用 C++ 编写的应用程序,另一个团队用 C# 重写了它,运行速度慢了大约 3 倍。自发布以来,我很好奇并与他们进行了更多讨论,询问他们是否可以通过一些额外的工作将其速度提高到至少接近与 C++ 相同。

他们的回答实质上是他们已经完成了额外的工作,而且只是“一点点”。 C# 重写大约花费了 3 1/2-4 个月。当时,他们用了不到一个月的时间就复制了原版的功能;剩下的全部时间都花在了(试图)让它足够快以可用上。

我赶紧警告 1) 这只是一个数据点,并且 2) 我不知道它与您可能做的任何事情有多接近。尽管如此,它确实让您了解当(如果)您开始进行真正的计算而不是仅仅将数据从网络传递到屏幕时可能遇到的那种减速。同时,快速看一下,它与 Computer Language Shootout 上的结果基本一致。网站——但请记住,这里的结果是针对 Mono 而不是 Microsoft 的实现。

至少对我而言,真正的问题归结为:您对性能的担忧是否真的有根据?对于大约 90% 的应用程序,重要的只是代码执行您希望它执行的操作,执行速度无关紧要,只要它不会太过分 较慢(例如,慢数百或数千倍)。如果您的代码属于那个(大)类别,C# 很可能是一个不错的选择。如果您确实有充分的理由担心执行速度,那么在我看来选择 C# 会很多更有问题。

关于c++ - VC++/C++ 高性能多线程GUI交易注意事项,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2827104/

相关文章:

Java线程,线程完成后如何释放资源

ios - Alamofire 请求完成后如何在后台线程中解析 JSON?

c++ - 使用模板查找最大值

c# - 从/向 native 插件传递 wchar_t 字符串 - 仅适用于 Windows?

python - 是否可以将网络驱动器添加到 %PATH% 环境变量

windows - 在 Windows 机器上开发,在 Linux (Ubuntu) 上部署

multithreading - react-native 是否支持多线程和后台线程或并行执行?我们怎么做?

c++ - 满足条件时是否可以在 GLSL 着色器中回调 C/C++ 函数/代码?

c++ - 混合 C 和 C++、原始指针和( boost )共享指针

C++ 在 Exe 中修补调用