使用DotTrace问题进行内存分析

Question

我在我的应用程序上运行了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-”等。与其他类似大小的文件，它挣扎着调整大小，但在几秒钟内打开。

这与textbox属性有关吗？我将其设置为multiline，并将最大字符数设置为0(因此没有限制)。

我该如何解决这个问题？有没有什么方法可以让我看到这些函数中调用了什么？

Answer 1

分析器显示大多数执行都发生在这些Windows API调用中，这是正常的。CallWindowProc()运行控件的默认消息处理程序时，您正在测量内置到Window中的本机编辑框控件处理文本文件所需的时间。WaitMessage()旋转，等待来自Windows的消息，告诉它发生了一些有趣的事情。这使得分析GUI代码变得困难，您必须将您编写的代码提升到单元测试样式的程序中。在这里并不实用，您没有编写任何占用所有CPU周期的代码。

您的问题是TextBox不是一个非常好的文本编辑器。它没有任何在成熟的编辑器中可以找到的优化。一定要关闭WordWrap属性，这特别昂贵。确保不要从文件中逐行填充TextBox，这是非常慢的，因为本机控件必须不断地重新分配其缓冲区。使用File.ReadAllText()或StringBuilder，然后指定文本。

像开源ScintillaNET这样的东西做得要好得多。