相关疑难解决方法(0)

我最近从Delphi 4升级到Delphi 2009.使用Delphi 4,我一直使用Primoz Gabrijelcic的GpProfile作为分析器,使用Turbo Power的Memory Sleuth进行内存分析和泄漏调试.两者都适合我.但我现在需要能够与Delphi 2009配合使用的新工具.

对于Delphi的分析/分析工具的领导者显然是AutomatedQA的AQTime.他们最近甚至吞噬了Atanas Soyanov的Memproof,据我所知这是一款出色的免费记忆分析工具,并将其功能融入AQTime.但AQTime对于个人程序员来说非常昂贵.它实际上比升级到Delphi 2009成本更高!

所以我的问题是:是否还有其他较便宜的选项可以在当前版本的Delphi中进行性能分析和内存分析,您对此感到满意并推荐,或者我应该咬紧牙关并为AQTime付出巨额代价？

Addenum:似乎早期的回答者表明已经包含在Delphi中的FastMM管理器非常适合发现内存泄漏.

那么,源代码分析有什么好的选择吗？

我很好奇的是Michael Adolph的ProDelphi,它不到AQTime成本的六分之一.你用它吗？AQTime值六倍的价值吗？

Addenum 2:我下载了AQTime和ProDelphi的试用版.

AQTime起初有点压倒性,有点令人困惑.花了几个小时才找到了解决它所需的一些技巧.

ProDelphi非常像我习惯的GpProfile.但是它的窗户混乱而且令人困惑,而且它不如GpProfile那么好.

对我来说,差异似乎是:

1. ProDelphi会更改您的代码.AQTime没有.如果出现问题,更改代码可能会损坏您的数据,但我对GpProfile的体验是它从未发生在我身上.加一个AQTime.

2. ProDelphi要求您关闭优化.但是你想要描述的是你的程序,它的优化程度,运行方式.加一个AQTime.

3. ProDelphi只能剖析功能或程序.AQTime可以归结为单独的线路.AQTime加2.

4. ProDelphi有一个免费版本,可以分析20个例程,其专业版本的成本不到100美元.AQTime是600美元.ProDelphi加4.

目前比分是4-4.你怎么看？

Addenum 3:Primoz Gabrijelcic计划让GpProfile再次运作.请参阅他对以下一些回复的评论.他在StackOverflow上饰演Gabr.

Addenum 4:看起来似乎可能有一个分析器解决方案.参见Andre的开源asmprofiler,如下所述.

我有一个Delphi 2009程序,它处理大量数据,需要尽可能快,不要使用太多内存.

您通过显着减少执行时间或内存使用对Delphi代码进行了哪些小的简单更改,这些更改对程序的性能影响最大？

谢谢大家的所有答案.很多很棒的提示.

为了完整起见,我将发布一些关于Delphi优化的重要文章.

在开始在About.com上优化Delphi代码之前

速度和大小: About.com 上的十大技巧

高性能Delphi中的代码优化基础和Delphi优化指南,与Delphi 7相关但仍然非常相关.

我很困惑.在CodeRage今天,Marco Cantu说CharInSet很慢,我应该尝试使用Case语句.我在我的解析器中这样做,然后用AQTime检查加速是什么.我发现Case语句要慢得多.

执行的4,894,539次:

而不是CharInSet(P ^,['',#10,#13,#0])做inc(P);

时间为0.25秒.

但执行次数相同:

而确实是     ',#10,#13,#0的
  案例P ^
:break;
    else inc(P);
  结束;

"while True"需要0.16秒,第一种情况需要0.80秒,else情况需要0.13秒,总计1.09秒,或者超过4倍.

CharInSet语句的汇编代码是:

添加edi,$ 02
mov edx,$ 0064b290
movzx eax,[edi]
调用CharInSet
测试a1,a1
jz $ 00649f18(返回add语句)

而案例逻辑就是这样:

movzx eax,[edi]
sub ax,$ 01
jb $ 00649ef0
sub ax,$ 09
jz $ 00649ef0
sub ax,$ 03
jz $ 00649ef0
add edi,$ 02
jmp $ 00649ed6(返回movzx声明)

案例逻辑在我看来是使用非常有效的汇编程序,而CharInSet语句实际上必须调用CharInSet函数,该函数在SysUtils中并且也很简单,是:

function CharInSet(C:AnsiChar; const CharSet:TSysCharSet):Boolean;
begin
结果:= CharSet中的C;
结束;

我认为这样做的唯一原因是因为在Delphi 2009中不再允许['',#10,#13,#0]中的P ^,因此调用会转换类型以允许它.

尽管如此,我对此感到非常惊讶,仍然不相信我的结果.

AQTime是否测量错误,我在这个比较中遗漏了什么,或者CharInSet真的是一个值得使用的有效函数吗？

结论:

我想你明白了,巴里.感谢您抽出宝贵时间做详细示例.我在我的机器上测试了你的代码,得到了.171,.066和.052秒(我猜我的桌面比你的笔记本快一点).

在AQTime中测试该代码,它给出:三次测试的0.79,1.57和1.46秒.在那里,您可以看到仪器的大量开销.但令我惊讶的是,这种开销将明显的"最佳"结果改为CharInSet函数,这实际上是最差的.

所以Marcu是正确的,CharInSet更慢.但是你无意中(或者可能是故意的)通过在Set方法中提取CharInSet用AnsiChar(P ^)做的事情给了我一个更好的方法.除了比case方法更小的速度优势,它也比使用案例更少的代码和更容易理解.

您还让我意识到使用AQTime(以及其他仪器分析器)进行错误优化的可能性.知道这一点将有助于我决定使用Delphi的Profiler和内存分析工具,这也是我的问题的另一个答案AQTime如何做到这一点？ …

在开发工具方面,我是一个犹豫不决的升级程序.对于我产品的大约一半,我仍然使用D7,而对于其他D2006.

事实是,虽然Unicode支持非常受欢迎并且非常有用,但它可能会让我遇到麻烦而不是当前项目的收益(它们已经或多或少已经准备好了).特别是如果每​​个字符串占用的内存是以前的两倍,那么其中一个人的性能会受到很大影响.

那么,除了Unicode之外,升级的其他主要动机是什么？

我正在使用Delphi7(非unicode VCL),我需要在TFileStream中存储大量WideStrings.我不能使用TStringStream,因为(宽)字符串与二进制数据混合,预计格式会加速加载和写入数据...但是我相信当前我正在加载/写入字符串的方式可能是我的代码的瓶颈......

目前我正在写一个字符串的长度,然后用char写它char ...加载时,首先我加载长度,然后加载char的char ...

那么,将WideString保存并加载到TFileStream的最快方法是什么？

提前致谢

我有一个程序,我在多台网络PC上运行.当我编译最新版本时,它在网络上的2台PC上运行得非常慢,但对其他人来说运行正常.

当我安装了额外的2GB RAM时,这曾经发生在旧的开发PC上.当我删除额外的2gb并重新编译时,它将适用于所有人.

现在,我正在使用一台全新的机器并遇到同样的问题.我重新启动后尝试重建项目,但仍然有同样的问题.

对于所有其他PC,程序加载大约3-5秒.在这两台PC上,加载时需要45秒到1.5分钟......

其中一台PC是较旧的戴尔Dimension 8200,但另一台则是较新的OptiPlex,它与网络上的其他几台PC完全相同,所以这才真正令人困惑.

现在,我不得不恢复旧版本,以便它能够为每个人正确运行.

有没有人想知道要尝试什么？

提前致谢!!!

编辑:

好吧,昨天是一个疲惫的一天,尝试各种方法来解决这个问题.这是我尝试过的问题以及问题的开始:

使用新程序

回到所有更新组件的旧版本,但仍然有同样的问题

使用旧程序

我决定回到绘图板并从旧版本的应用程序开始,逐步添加新功能.

1. 使用旧组件重新编译旧版本 - 程序运行正常
2. 更新到新的DevExpress组件 - 程序运行正常
3. 更新到新的ESBPCS组件 - 程序运行正常
4. 更新到新的DeepSoftware组件 - 程序运行正常

好的,现在我们知道我更新的组件集没有任何内容......

1. 为2个图像列表中的每一个添加了1个图像 - 程序运行正常
2. 添加了新的数据库表 - 程序运行正常
3. 添加了打开和关闭新表的代码 - 程序运行正常
4. 添加了新动作到动作列表,并为新动作添加了一个菜单项和工具栏按钮(动作此时不执行任何操作) - 程序运行正常
5. 为应用程序添加了一个新的BLANK表单,并添加了代码以打开新表单 - BAM!

因此,只在应用程序中添加一个表单就是导致问题的原因!我删除了打开表单的所有代码,注释掉了uses子句并从项目源中删除了uses条目,一切都恢复正常了!

有人对此有任何想法吗？

谢谢!

编辑2:

对于@Warren P - 这是我的.DPR来源:

program Scheduler;

uses
  ExceptionLog,
  Forms,
  SchedulerMainUnit in 'SchedulerMainUnit.pas' {FrmMain},
  SchedulerDBInfoUnit in 'SchedulerDBInfoUnit.pas' {FrmDBInfo},
  SchedulerHistoryUnit in 'SchedulerHistoryUnit.pas' {FrmHistory},
  SchedulerOptionsUnit in 'SchedulerOptionsUnit.pas' {FrmOptions},
  SchedulerExtVersionUnit in 'SchedulerExtVersionUnit.pas' {FrmExtVersion},
  SchedulerSplashUnit in 'SchedulerSplashUnit.pas' …