我在我的应用程序上运行了dotTrace（这有一些问题）。
IntPtr System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
Void System.Windows.Forms.UnsafeNativeMethods.WaitMessage()
是否出现了两个主要功能，占用了大约94％的应用时间。
由于我不知道这两个函数是什么，所以我逐行浏览了我的代码。它运行平稳有效，直到它刚刚挂起。 “newFrm.Show（）”。
newFrm只包含一个文本框。我加载到文本框中的文件越大（它是一个记事本程序），它需要的时间越长。现在通常这是有道理的，但167 kB文件大约需要30秒。
现在我不知道该怎么做。当您加载文本文件并尝试调整包含文本文件的窗口时，它会运行速度极慢/停止运行。
然后我意识到它只是在努力打开带有长串十六进制内容的文本文件（即）“XX-XX-XX-”等。对于其他类似大小的文件，它在某种程度上调整大小，但是在几秒钟。
这是否与文本框属性有关？我已将其设置为多行并将最大字符设置为0（因此无限制）。
如何解决此问题？有什么方法可以看到这些函数中调用的内容吗？
答案 0 :(得分：2)
分析器显示大多数执行都发生在那些Windows API调用中是正常的。 CallWindowProc（）运行控件的默认消息处理程序，您正在测量Windows内置的本机编辑框控件处理文本文件所需的时间。 WaitMessage（）旋转，等待来自Windows的消息发生了一些有趣的事情。这使得分析GUI代码变得困难，您必须将您编写的代码提升为单元测试样式程序。这里不实用，你没有编写占用所有CPU周期的任何代码。
你的问题是TextBox不是一个很好的文本编辑器。它没有你在一个成熟的编辑器中找到的任何优化。一定要关闭WordWrap属性，这是特别昂贵的。并且请确保不要从文件中逐行填充TextBox，因为本机控件不断重新分配其缓冲区，所以非常慢。使用File.ReadAllText（）或使用StringBuilder，然后指定Text。
像开源ScintillaNET之类的东西做得更好。