问Delphi分析工具

EN

不久前我问过同样的question

我已经下载并试用了AQtime。它看起来确实很全面，但它不是一个易于使用的工具，而且对于单个程序员来说非常昂贵(即600美元)。我喜欢它是非侵入性的(没有更改您的代码)，并且它可以逐行分析，直到我发现因为它是一个检测分析器，所以它可能导致不正确的优化，如：Why is CharInSet faster than Case statement?

我尝试了一个ProDelphi的演示，价格要便宜得多(我想大约80美元)，但它对我来说太笨拙了-我一点也不喜欢用户界面，而且它是侵入性的-修改代码来添加插装，这一点你必须小心。

我在Delphi4中使用GpProfile已经有很多年了。我很喜欢。它也是侵入性的，但它工作得很好，我学会了信任它，10年来它从未给我带来任何问题。但当我升级到Delphi 2009时，我认为尝试使用它并不是最好的选择，因为它还没有升级，而且据GP承认，没有修改就不能工作。我希望你在Delphi2006中也不能使用它。

ProDelphi和GpProfile将仅在过程级别进行评测。如果你想处理单独的代码行(我有时不得不这么做)，你必须为每一行调用PROC1，PROC2，PROC3，并在每个进程中放入一行。不得不这样做有点恼人，但它给了我很好的结果(至少我对GpProfile这样做的结果很满意)。

我在CharInSet问题中接受的答案是：“定期检查CPU位置的采样分析器通常更适合测量代码时间。”后来，answer提供了Eric Grange的用于Delphi的免费采样分析器，现在支持Delphi2009。我还没有尝试过，但我听到了一些关于它的好消息，这是我下一次要尝试的。

顺便说一句，你最好省下600美元，不买AQtime，而是用它把你的Delphi2006升级到Delphi2009。稳定性，速度和额外的功能(特别是Unicode)，将是值得你花时间的。请参阅：What are major incentives to upgrade to D2009 (Unicode excluded)?

此外，AQtime还没有集成到Delphi2009中。

另一个免费的是TProfiler，它的源码是我发现的，但还没有尝试过。如果有人尝试过这个方法，我想知道他们的想法。

注意:我后来添加到question 291631中的Addenum似乎就是答案。请参阅Andre's open source program: asmprofiler

2010年2月跟进。我咬紧牙关买了AQTime。几个月前，他们终于将其集成到我使用的Delphi2009中(但他们仍然必须使用Delphi2010)。查看源代码行以及它们各自的时间和计数对我来说是无价的，AQTime在这方面做得很好。

我刚刚找到了一个非常好的免费sampling profiler，它支持Delphi2009

我使用了ProDelphi，主要是用来确定哪些例程消耗的时间最多。它是一个工具分析器，这意味着它会在每个例程的开头和结尾添加一些代码。您可以通过注释中的指令来控制它分析的例程。您还可以分析例程的各个部分。但是段必须在相同的块级开始和停止，不能进入或退出段。优化必须在ProDelphi插入代码的地方(放置指令的地方)关闭，但您可以在其他任何地方打开它。

界面有点笨拙，但一旦你掌握了它的诀窍，它就会变得非常快。您可以使用免费版本(限制为10个例程或部分)进行有用的工作。ProDelphi可以快速告诉您应该检查哪些例程。但不是为什么，也不是哪一行。

最近，我开始使用英特尔的VTune性能分析器。“‘WOW”并没有开始总结它。我是印象深刻的。我根本不知道所有这些都内置到了现代英特尔处理器中。您知道吗?它可以准确地告诉您，在从更高的高速缓存重新加载一个字之前，单个指令需要等待L1数据高速缓存横向查看另一个核心的频率是多少？如果我继续写下去，我听起来就像是在为产品做一个令人屏息的广告。

访问英特尔并下载全功能timed演示。在网上翻找一些关于如何入门的视频。(否则，您将面临被所有选项阻碍的风险。)它适用于任何编译器。只需将其指向.exe即可。如果您的.exe包含调试信息，它将显示源代码行&您可以将其指向源代码。

我被困在试图优化一个调用我写的函数的内部循环。除了长度(Str)之外，没有外部调用。这个内部循环每次运行数十亿次，消耗了大约一半的cpu时间--这是一个完美的优化候选者。我尝试了所有的标准优化，但几乎没有效果。VTune显示热点。我一直往下钻，直到它显示出我的代码生成的ASM，以及每条指令所花费的时间。

这是VTune告诉我的：

• line nnnn行delphi代码...
• addr hhhh cmp byte ptr edx+ecx,0x14h ---3 cycles
• addr hhhh ja label_x -- -10302 cycles

绝对值没有任何意义。(我想我是在测量每个失效指令的周期。)相对值让我们很清楚所有时间都花在了哪里。最棒的是建议窗口。它告诉我代码会等待数据加载到L1数据缓存中而停止，实际上还给了我关于如何避免停止的好建议。

我的错误在于我认为Core2 Quad只是一个非常快的8086CPU。代码花费了99%的时间等待从内存中加载数据，因为我跳得太多了。我的算法假设内存是RAM (随机存取)。这不是现代CPU的工作方式。L1缓存中的数据可能在1到2个周期内被访问，但访问L2或L3缓存需要数十到数百个周期，而访问RAM需要数千个周期。然而，在中，当您按顺序访问数据时，所有的延迟都可以避免--因为处理器将用您请求的第一个字节后面的数据预加载缓存。

Net的结果是，我重写了算法，以更顺序地访问数据，并获得了10倍的加速，这已经足够好了。当我有时间的时候，我确信我可以再得到10倍的回报。但那只是我身上的极客。足够好就足够好了。

我已经知道，通过优化你的算法，而不是你的代码，你会得到最大的成功。我认为我只需要分析器来告诉我需要优化什么。但我也需要它来找出瓶颈的原因，这样我就可以设计一个更快的算法。

新的算法与旧的算法没有根本的不同。它只是存储数据，以便可以按顺序访问。例如，在一个地方，我将一个字段从记录数组移动到它自己的整数数组中--因为内部循环不需要每条记录中的其余数据。我还有一个矩形矩阵，存储为动态数组的动态数组。代码使用它来随机访问兆字节的数据(而糟糕的L1数据缓存只有64Kb)。我想出了如何将其存储在线性数组中，作为矩阵的对角线，这是我使用数据的顺序。(好吧，也许那部分是的词根。)

不管怎么说，我被VTune迷住了。