对于我们的开源ORM框架

当使用Delphi 7,Delphi 2007和Delphi 2010编译器运行our unit tests时,我发现Delphi 7和Delphi 2007之间的速度有所改善,但Delphi 2007与2010年之间并不明显.Delphi 2010生成的代码被发现甚至更慢.我手头没有Delphi XE编译器,但我猜这是Delphi 2010有点相似 – 主要是关于泛型的错误修复,AFAIR.

当我写低级别的pascal代码时,我在asm视图(Alt-F2)中花了很多时间,并使用了一个分析器.所以我通常会注意到Delphi编译器版本之间的区别.

IMHO的主要改进确实是方法和功能/程序的inline关键字,在Delphi 2007中可用,而不是在Delphi 7中.另一个改进是更积极的注册重用.

浮点生成代码仍然很慢,有时是awfull(FWAIT仍然生产,即使不再需要了,内联浮点代码甚至可以是worse than with no inlining！

我们的框架有趣,所有这些测试都是处理大量数据,使用自己的低级单元,以非常调优的pascal编码,以获得最佳性能.提供的单元测试(超过5,400,000个单独的测试)对实际数据(数字转换或UTF-8文本处理)工作,具有许多不同的过程,包括低级转换,文本解析,对象分配,多线程和客户端/服务器方向.所以在这里,编译器生成的代码确实有所作为.

代码主要在我们的框架内.我们使用我们自己的RawUTF8字符串类型,而不是通用字符串.因此,瓶颈不是VCL而是Windows API,而只是纯Delphi的编译代码.实际上,即使对于UTF-8编码或数字转换,我们也避免了大部分的API调用.

当然,我用PUREPASCAL条件集尝试了这个基准,即不在asm中运行优化的部分,而只依靠“纯pascal”代码.

2.对于SynLZ压缩单元

另一个有关速度的好的实验是在编写和分析我们的SynLZ compression unit.通过LZ压缩算法的优化实现,压缩比zip快20倍,减压速度提高了3倍.事实上,它与LZO竞争压缩比和解压缩速度,但是比LZO压缩速度快得多：SynLZ能够以与解压缩相同的速率来压缩数据.这种对称的实现在压缩世界中是非常罕见的.

它仅涉及整数算术和位逻辑,哈希表中的填充和查找以及内存副本.

我们写了一些非常调优的pascal代码,然后用Delphi 7和Delphi 2009进行编译.

Delphi 2009生成的代码比Delphi 7快得多,效果显着.生成的代码确实更好,更好的寄存器重用.

通过手动调试汇编程序,我们实现了更好的性能.例如,6 KB XML文件使用zip压缩为14 MB / s,使用LZO为185 MB / s,使用Delphi 2009 pascal版本的SynLZ为184 MB / s,使用最终调整的asm版本为256 MB / s SynLZ.

结论：

对于生成涉及整数处理,文本解析或内存的代码,我认为Delphi XE比Delphi 7要快,但应该与Delphi 2007大致相同.内联是主要的新功能,可以加快很多代码.

但对于现实世界的应用来说,速度的提升并不明显.在某些具体情况下,约10％或20％,而不是更多.算法始终是提高性能的关键. Delphi 7已经是一个很好的编译器.

对于浮点运算,Delphi编译器现在已被弃用.我希望64位编译器中的SSE代码会在这里改变结果.

直接回答您的问题,在Delphi 2010或XE中,没有自动内联和自动循环展开AFAIK.多线程代码的开销不是编译器的一部分,而是在库(FastMM4,引用计数等)上.所以我不认为Delphi XE比Delphi 2007产生更快的代码.