c# – UI调度缓冲？

概述我有一个难题.我“继承”了一个非常糟糕的设计和非常复杂的系统,我正在进行现代化和重建(与我的团队一起).问题是当前系统依赖于200个用户,并且由于(缺乏)设计,他们在性能方面存在重大问题.目前最棘手的问题是在UI线程上放置了大量的工作,这导致GUI挂起,直到线程被清除并且消息泵送可以继续.这项工作大部分确实需要在GUI线程上,因为由于其他线程上的其他计算结果,它正在更新网格中的大量字段. 问题是： 我有一个难题.我“继承”了一个非常糟糕的设计和非常复杂的系统,我正在进行现代化和重建(与我的团队一起).问题是当前系统依赖于200个用户,并且由于(缺乏)设计,他们在性能方面存在重大问题.目前最棘手的问题是在UI线程上放置了大量的工作,这导致GUI挂起,直到线程被清除并且消息泵送可以继续.这项工作大部分确实需要在GUI线程上,因为由于其他线程上的其他计算结果,它正在更新网格中的大量字段.

问题是：我没有资源专门用于重写这里涉及的线程模型和底层类,而且这项工作的复杂性会带来很大的风险,这对我的客户来说是不可接受的.

我想知道是否有人有任何关于如何使UI更高效的建议,而不会过多地干扰currnet线程模型.

我最初的想法是,可能有某种方法可以在UI线程的实际调用之前放置一个“缓冲区”,以确保GUI不会过载,或者什么时候退出调度到它.

任何建议将不胜感激.

我知道这些都不是理想的,但我们就是这样,我真的希望在为期一年的重写完成之前为用户提供更好的体验！

谢谢！

更新#1
这是一个winforms应用程序……对不起,这一开始并不清楚.新代码是WPF,但这些模块是winforms.

更新#2
我想我可能最初尝试将大多数BeginInvoke调用更改为UI线程调用Invoke,引入序列化,希望能够提高UI响应能力.
这里有任何(非显而易见的)缺点,任何人都可以预见到吗？

解决方法 我不知道它是否会在你的特定情况下起作用,但我过去一直处于类似的(尽管可能不那么紧张)的情况,而我在 came up with some code中让我从背景中编组了或多或少的任意代码线程到UI线程.这是在WinForms时代写的.

这可能会为您提供一种风险较低的技术,让您可以在某些后台线程上重新计算一些计算,并且可以更轻松地将UI更新编组到前台,而无需完整地重新构建线程模型(或缺少线程模型).

关于UI的性能,有时提高速度的最佳方法是做得更少.我创建链接代码时正在处理的应用程序是解析数百兆字节的字符串来手动munge一些xml.用stringbuilders替换不可变字符串使得 *** 作从OOM失败状态到挂钟时间的5分钟内完成.然后我注意到,对于它解析的每个元素,它都更新了UI.我调整了代码来每隔50个元素更新一次ui,并将其缩短到一分钟.关闭所有UI更新会将时间缩短到几秒钟.

在计算完成之前,您是否考虑过不更新UI,可能只是运行进度条？另一种可能性(在我的头顶,不知道它有多邪恶)是将更新排队为字典中的lambdas,该字典是关闭控件的更新.这样,如果单个控件多次更新,则可以将冗余更新替换为值,例如,(这假设应用程序不是直接从UI读取值来执行计算.当然.它可能是.:()

总结

以上是内存溢出为你收集整理的c# – UI调度缓冲？全部内容，希望文章能够帮你解决c# – UI调度缓冲？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。