VC++ / C++ 高性能多线程 GUI 注意事项（适用于交易）

Question

VC++ / C++ 高性能多线程 GUI 注意事项（适用于交易）

c++windowsmultithreadingqtmfc

8

我对于在Windows平台上开发高性能多线程GUI时，有经验的开发人员所做的考虑感兴趣。我在开发交易应用程序的背景下提出这个问题，其中GUI非常动态且应用程序延迟是一个问题。

在这种情况下，您看到或推荐使用哪些体系结构来实现观察者模式，而不是MFC文档/视图？我认为由于性能问题，不会使用文档/视图。

需要考虑哪些特定因素来更新在单独线程中更新的UI组件/窗口，无论是在MFC还是Qt中？是否有任何适用于所有GUI库的通用规则？

- Raf

你真的认为Document/View会增加不可接受的开销吗？现在大多数交易GUI都是用.Net编写的。甚至在2000年，我也参与了一个基于Web的交易系统，在交易所现场与交易数据并行运行时，延迟是无法察觉的。话虽如此，我肯定会放弃MFC，但是我已经有好几年没有做过C++ GUI工作了，所以不能评论现在最好的框架是什么。我知道Qt得到了很多关注。 - philsquared

你能否给我们一些关于你的GUI复杂程度的想法，比如什么样的图表以及它们的数量，以及它们需要多频繁地更新等？ - MusiGenesis

@Phil：根据我在城市交易软件公司的技术面试中得出的结论，文档/视图将是一种不可接受的开销。 - Raf

@MusiGenesis：基本上包括各种技术分析图表，如蜡烛图、移动平均线、相对强度、价格、成交量、自动支撑/阻力水平。此外还有屏幕显示实时下单情况，即二级数据和新闻源。关于数据的屏幕数量/视图，大约有30个。 - Raf

最大更新频率为250毫秒。 - Raf

当您提到延迟时，是指接收数据的延迟还是更新显示的延迟？ - PiNoYBoY82

3个回答

4

我曾经在一款交易应用程序的GUI界面上工作过。基本上，任何本地（即非Web）的东西都足够快。 C ++，C＃或Java都可以。使用C ++的主要缺点是它消除了计算代码和UI之间的自然障碍。我之前的程序员有些粗心，使用了C ++，因此计算代码和UI有些交织在一起。这使得Qt端口更加困难。

多线程对于UI来说大多不相关。但是，它应该在自己的线程上运行，这意味着只有与计算引擎接口相关的部分需要关注可能在其他线程上被调用的可能性。

- MSalters

喜欢你提到强制将表示层和数据/计算层分离的观点。 - Raf

3

自从你在评论中提到选择C++还是C#的问题后，我要推荐使用C#，特别是WPF（Windows Presentation Foundation）。理论上，C++应用程序的性能上限比.Net应用程序高，因为它没有处理.Net框架开销的负担。但是，它的开发时间可能会更长，并且更容易出现错误和内存泄漏。

如果你要编写自己的显示控件，WPF（甚至WinForms）足以处理这种控件负载（如果像任何语言/平台一样编写得正确）。此外，有大量的自定义控件可用于显示股票图表等内容，这将使构建此应用程序比从头开始编写所有内容更快。

- MusiGenesis

我同意使用.NET及其相关技术的所有好处。但是你认为伦敦金融城为什么对这些类型的应用程序仍然停留在C++上呢？我一直以为这是C ++在GUI应用程序方面比较优秀的少数领域之一。 - Raf

2

说实话，我曾在伦敦的几家投资银行工作过，似乎到处都在使用C#编写GUI，而计算库则使用C++（并使用COM或C++/CLI进行桥接）。除了一些即将淘汰的古老遗留系统外，我已经很长时间没有看到任何MFC GUI代码了。 - philsquared

知道这点很好。可能只是邀请我面试的公司对我很久以前做的 MFC 年限感兴趣，因为他们使用的是传统系统。也许我应该从简历中删除这部分内容。 - Raf

@Raf：“伦敦城市”对编程一窍不通，这是为“伦敦城市”工作的程序员利用自己的优势所在，使用有利于自己工作安全而损害雇主利益的平台/语言。C++通常非常快，但现在其他语言也同样如此（甚至Java和RoR除外）。我认为开发时间的成本远远超过软件中的其他任何因素。如果我真的要支付编写软件的费用，C++是我最后会使用的东西。 - MusiGenesis

好的，那可能有点极端了。当然，C++ 也有它的用处；我只是不确定这是否适用于此。 - MusiGenesis

这并不是绝对的。除了轻量级的系统托盘应用程序之外，在GUI方面使用C++几乎没有任何好处。然而，在计算方面，情况就不同了。这不仅仅是原始计算速度的问题——如果你在网格上分发小型计算，虚拟机的启动时间往往会占主导地位！ - philsquared

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jerry Coffin · Accepted Answer

你正在完全错误的地方寻找答案。文档/视图架构的"开销"只有纳秒级别（基本上，通过指针访问数据）。相比之下，屏幕可以有意义地更新的绝对最大速率是显示器的刷新率，通常为60 Hz（即每16.67毫秒一次）。即使是这种刷新速率，也不能在任何给定的监视器更新中真正改变太多内容--如果您试图改变太多，用户将无法跟踪发生了什么。至于线程，到目前为止最简单的方法是在一个线程中执行所有实际的窗口更新，并使用其他线程进行计算和生成用于更新窗口的数据等操作。只要确保该线程不需要进行大量计算等操作，就可以轻松地以任何有用的速度更新窗口。编辑：关于C++ vs. C#，这取决于情况。我毫不怀疑您可以从两者中获得完全足够的显示性能。真正的问题是在这些显示背后进行了多少计算。您提到的主要是显示接近原始数据（价格、交易量等）。对于这个，C#可能会很好。我的猜测是你所说的人在做的计算远比那多--这是.NET（或几乎任何运行在VM上的东西）真正的弱点。根据我所见，对于真正的重型计算，C#等并不是非常有竞争力。

仅为例子，在之前的回答中，我提到了一个应用程序，我最初用C++编写的，另一个团队用C#重写后运行速度变慢了3倍左右。自从发布以来，我很好奇并与他们交流了一些，问他们是否可以通过一点额外的工作来改善它的速度至少接近于C++。

他们的回复本质上是，他们已经完成了那些额外的工作，并且这不仅仅是“一点”。C#重写花了大约3个半到4个月的时间。其中不到一个月的时间就复制了原始版本的功能；其余全部时间都花在了（试图）使其快到足以使用的程度上。

我急忙提醒：1）这只是一个数据点，2）我不知道它与您可能做的任何事情有多接近。尽管如此，它确实可以让我们了解当您开始进行真正的计算而不仅仅是将数据从网络传输到屏幕时，您可能会遇到的减速类型。同时，快速查看表明，它通常符合Computer Language Shootout网站上的结果-请记住那里的结果是针对Mono而不是Microsoft的实现。

对我来说，真正的问题在于：你是否真正担心性能问题？对于大约90%的应用程序而言，重要的是代码执行所需的功能，执行速度并不重要，只要它没有变得极其缓慢（例如，几百或几千倍）。如果你的代码属于这个（大）类别，那么C#很可能是一个不错的选择。如果你真的有充分的理由担心执行速度，那么选择C#似乎就会有更多的问题。