使用任何实际数量的文本时，WPF的RTB非常慢。实际数量，我的意思是你期望任何文本编辑器能够处理（至少100kb？）而没有任何缓慢的迹象。
这种预期的RTB行为对我来说并非如此。实际上，当文本被整齐地分成小词和小段落时，控件的工作方式非常类似于我实现了一些机制，只要他们勇敢并且输入任何相当长的内容，就会消除我的用户。我还没有找到实现这种机制的方法，所以我不得不（或者至少试图）解决这个问题。
我发现这令人非常不安，因为它对我来说没有任何意义。如果你是一个胆大妄为的人，碰巧在没有空格或休息的情况下输入一长串字符，你就会成为锁定窗口的受害者几秒钟，这使得打字成为一种不受欢迎的耐心测试。我很想知道的是：为什么？具体来说，为什么当文本间隔不一致时，越来越多和 会减慢速度？我是否疯狂地考虑使用我的程序的人会有一个破损的空格键，因此更倾向于注意到这种令人难以置信的减速？在这个连续字符串的情况下，文本选择也受到严重影响。
我的目标是.NET 4.0，使用的是VS 2010，RTB上没有任何事件被挂钩;出于测试目的，它只是一个空窗口上的RTB（< RichTextBox />）。我该怎么做才能提高性能？为此编写自己的控件更为现实，将功能设置保持在最低要求吗？如果是这样，我们将非常感谢任何资源链接。
值得注意的是，RichTextBox中的数据量可能非常小;我试图弄清楚的是，文本的格式确实对性能影响最大。
答案 0 :(得分：1)
对于文本框的新实现，这不是一个不常见的问题。它与用于计算换行符的算法有关。根据您报告的行为类型，听起来他们使用的算法的效率很大程度上取决于长度或单词（即，相对于单词的长度，它可能是，例如，O（n ^ 2） ）。您应该直接向Microsoft报告（带有一个明确的示例），以便他们可以修复该错误。