Raf*_*Raf 7 c++ windows qt mfc multithreading
我有兴趣了解开发人员在为Windows平台开发高性能多线程GUI时所经历的考虑因素.我在开发交易应用程序的背景下提出这个问题,其中GUI是非常动态的,应用程序延迟是一个问题.
您看到了哪些体系结构,或者您是否建议在MFC文档/视图中查看以在此上下文中实现观察者模式.我认为由于性能问题,不会使用文档/视图.
需要对在MFC和Qt中的单独线程中更新的UI组件/窗口进行哪些具体考虑？是否有适用于所有GUI库的一般规则？
你正在寻找完全错误的地方.文档/视图架构的"开销"在纳秒范围内(基本上,通过指针访问数据).
为了进行比较,您可以有意义地更新屏幕的绝对最大速率是监视器的刷新率,通常为60 Hz(即每16.67毫秒一次).
为了使这种刷新率有意义,在任何给定的监视器更新中你都无法真正改变 - 如果你试图改变太多,用户将无法跟踪正在发生的事情.
就线程而言,到目前为止,最简单的方法是在一个线程中进行所有实际的窗口更新,并使用其他线程进行计算,从而为正在更新的窗口生成数据.只要你确保线程不需要做很多计算等等,就像任何使用一样快速更新窗口非常容易.
编辑:就C++与C#而言,它取决于.毫无疑问,你可以从任何一个中获得完全足够的显示性能.真正的问题是你在这些显示器后面做了多少计算.您所提到的主要是显示非常接近原始数据(价格,数量等).为此,C#可能会很好.我的猜测是,与你交谈过的人所做的计算量远远超过了这一点 - 这就是真正的阿基里斯治愈(或者几乎任何在VM上运行的其他事情).从我所看到的,对于真正重型计算,C#等并不是真正具有竞争力.
例如,在前一段时间的另一个回答中,我提到了一个我最初在C++中编写的应用程序,另一个团队在C#中重写,其运行速度慢了约3倍.发布之后,我很好奇,并与他们进行了更多的讨论,询问他们是否无法通过一些额外的工作来提高速度,使其至少与C++接近.
他们的回答是,在本质上,他们会已经这样做了额外的工作,这是不是只是"一点点".C#重写花了3 1/2-4个月.在那段时间里,他们花了不到一个月的时间来复制原作的特征 ; 其余的时间花在(试图)使其足够快以便可用.
我不得不提醒1)这只是一个数据点,2)我不知道你可能做的事情有多接近.尽管如此,它确实可以让您了解当您(以及如果)开始进行实际计算而不是仅仅将数据从网络传递到屏幕时可能遇到的减速类型.同时,快速查看表明它通常与计算机语言大战网站上的结果一致 - 但请记住Mono而不是Microsoft的实现结果.
至少在我看来,真正的问题归结为:你对绩效的关注是否真的有充分根据？对于像周围的应用程序的90%,最重要的是简单的代码做什么你想让它和执行的速度关系不大,只要它没有得到显着的时间慢慢(例如,数百或数千).如果您的代码属于那个(大)类别,那么C#可能是一个不错的选择.如果你真的有一个很好的理由要关心执行速度,那么在我看来,选择C#将是一个很多更值得怀疑.