我如何找出调整主窗体大小时长时间延迟的原因？答案

【问题标题】：How might I find out the source of long delays on resizing the main form?我如何找出调整主窗体大小时长时间延迟的原因？
【发布时间】：2011-03-02 19:33:46
【问题描述】：

我有一个 D2006 应用程序，它在选项卡上包含一个页面控件和各种网格等。当我调整主表单的大小时（它会波及并调整表单上与某物对齐的几乎所有内容），我会遇到很长的延迟，比如几秒钟。应用程序冻结，空闲处理程序没有被调用，正在运行的线程似乎也暂停了。

我尝试在发生这种情况时暂停 IDE 中的执行，试图在麻烦的代码中中断执行，但 IDE 不接收消息。

显然，我不希望有人指出一些错误的代码，但我正在调试可能对我有帮助的方法。我在整个应用程序中都有大量的执行时间代码，并且长时间的延迟不会出现在任何数据中。例如，主窗体 OnResize 处理程序的执行时间最短。

【问题讨论】：

那么这些线程正在等待主线程，可能是因为Synchronize。
“网格”中有什么或者是什么？ DBGrid/StringGird?
@Despatcher - 它们是 TDrawGrid 和 TStringGrid。 DrawGrids 都是从内存中的东西渲染出来的
不要忘记 AQTime，它是一个很棒的分析器。 Rad/Delphi XE 附带一个精简版，我认为有试用版。这是商业的，值得。

标签： delphi forms freeze delphi-2006 onresize

【解决方案1】：

如果您想了解实际占用您时间的原因，请尝试使用分析器。 Sampling Profiler 可以很容易地回答您的问题，特别是如果您能够找到导致问题的代码部分的开头和结尾并在其周围插入 OutputDebugString 语句以缩小分析范围。

【讨论】：

嗨@Mason。我在模块“SamplingProfiler.exe”中的地址 0040770B 处得到 ---------------------------- 访问冲突。读取地址 00E30000。 --------------------------------------- 当我尝试开始分析时。
@rossmcm：然后尝试在论坛上报告它。如果你能想出一个可重现的测试用例，访问违规很容易追踪。
“您的帐户仍在等待管理员批准”

【解决方案2】：

好的。问题解决了。我注意到只有在启用命令行开关以记录一些调试信息时才会出现问题。调试信息包括一些 HTTP 响应，这些响应写入其中一个选项卡上的调试日志（TMemo）。当 HTTP 响应包含一个没有 CR/LF 的大块时，TMemo 会包装它。每当我调整主窗体的大小时，TMemo 都会调整大小，并且控件必须使用新的自动换行再次呈现文本。

演示：

开始一个新的 Delphi 项目
将 TMemo 拖放到表单上
将其与客户端对齐
编译运行
将大量文本粘贴到 TMemo 中
调整主窗体的大小

我不会给自己答案，因为我没有真正提供足够的信息让其他人解决它。

顺便说一句 @Mason - SamplingProfiler 会选择这个 - 鉴于执行是在 VCL 内部，而不是在我的代码中？

【讨论】：

是的，它会的。它通过对程序状态进行采样并将其与映射文件进行比较来工作，并且映射文件包含标准库和代码的数据。（这并不一定意味着如果您不熟悉 VCL 内部结构，您很容易理解数据，但它肯定会掌握它。）
如果关闭 TMemo 自动换行，它会变得更快吗？
@Warren，如果文本足够长，可以换行，则要提高几个数量级

【解决方案3】：

可能会产生结果的蛮力方法.... 从每个 re-size 事件中将调试消息发送到 OutputDebugString()，将控件的名称作为要显示的字符串发送。这可能会告诉你哪些被称为“很多”。

您可能会遇到控件相互碰撞的情况，从而引发级联的调整大小事件。就像紧凑型汽车后座的 3 个兄弟姐妹一样，一旦他们开始争夺位置，他们可能需要一段时间才能“安顿下来”。

别让我把这辆车转过来……

调试日志（可在 IDE 中查看，或使用外部 ODS 查看器查看）可能会向您显示哪些日志会导致最大的问题，如果它们针对一个“用户发起的调整大小事件”多次出现。

【讨论】：

【解决方案4】：

在 AQTime 的性能分析器中运行您的应用程序（包含在 XE 中，但您可以从他们的网站获得限时版本）。

进行一段时间的疯狂调整，然后停止应用程序。

之后，您将确切地看到哪个函数被调用了多次，以及大部分时间都花在了哪里。

【讨论】：