我有一个D2006应用程序，其中包含选项卡上的页面控件和各种网格等。当我调整主窗体的大小时（它会在与某些东西对齐的表格上涟漪并调整大小），我会遇到很长的延迟，比如几秒钟。该应用程序冻结，未调用空闲处理程序，并且正在运行的线程也会暂停。
我试图在IDE中暂停执行，而这种情况发生在试图破坏执行时，它处于麻烦的代码中，但IDE没有接收消息。
显然，我不希望任何人指出我的错误代码，但我正在调试可能对我有帮助的方法。我在整个应用程序中都有大量的执行时序代码，并且长时间延迟不会显示在任何数据中。例如，主窗体OnResize处理程序的执行时间是最小的。
答案 0 :(得分：5)
如果您想了解实际占用时间的内容，请尝试使用分析器。 Sampling Profiler可以非常轻松地回答您的问题，特别是如果您能够找到导致问题的代码部分的开头和结尾，并在其周围插入OutputDebugString语句来缩小分析范围。< / p>
答案 1 :(得分：3)
行。问题解决了。我注意到问题只发生在我启用命令行开关来记录一些调试信息时。调试信息包括一些HTTP响应，这些响应被写入其中一个选项卡上的调试日志（TMemo）。当HTTP响应包含没有CR / LF的大块时，TMemo将其包装起来。每当我调整主窗体的大小时，TMemo都会调整大小，控件必须使用新的自动换行再次渲染文本。
演示：
我不会给自己答案，因为我没有真正提供足够的信息供其他人解决。
BTW @Mason - SamplingProfiler会选择这个 - 假设执行是在VCL中，而不是在我的代码中？
答案 2 :(得分：2)
可以给出结果的强力方法....从每个重新调整大小的事件向OutputDebugString（）发出调试消息，将控件的名称作为要显示的字符串发送。这可能会告诉你哪些被称为“很多”。
您可能遇到控件相互碰撞的情况，引发了级联重新调整大小的事件。就像紧凑型轿车后座的3个兄弟姐妹一样，一旦他们开始争抢位置，他们可能需要一段时间才能“安定下来”。
不要让我把这辆车转过来......
调试日志（可在IDE中查看，或使用外部ODS查看器查看），如果一次“用户启动的重新调整大小事件”出现多次，则可能会显示哪些是最麻烦的。
答案 3 :(得分：2)
在AQTime的性能分析器中运行您的应用程序（包含在XE中，但您可以从他们的网站获得有时间限制的版本）。
做一些狂热调整一段时间，然后停止应用程序。
在那之后，你会看到确切地调用了哪个函数，以及花费了大部分时间。