Delphi 代码优化（转）

Delphi强力优化

    nightmare(qingrui li)

**关于记录类型的返回值
C++程序员不会这样做，因为返回值会被压入堆栈，导致时间效率和空间效率都降低。但Delphi无此问题。一般情况下，记录类型返回值会像Out参数一样传递引用（在EAX寄存器中）。

**公共表达式
Delphi只在一个语句行内提取公共表达式。如果公共表达式包含函数调用，则不会被提取，因为可能改变语义。如果确保函数返回值相同，应预先计算。

**类属性
每次引用属性时都会使属性重新计算，即使属性是直接映射到域。频繁调用属性时应预先计算。

**循环内的重复计算表达式外提
C++程序员可能会让编译器做此优化，但Delphi一般不会这么做。最安全且最有效的优化应由程序员来完成。

**使用const参数
当函数参量不被改变时，如果参量长度超过4字节或是接口、字符串、动态数组类型，使用const参数，可以使编译器尽可能的以地址方式用寄存器传递。

**长度为4字节的记录或数祖赋值时，编译器会自动按DWORD用32位寄存器处理

**记录数组的元素长度是偶数的话，可以生成更快的数组访问代码

**整除2或4会优化成右移位，乘2或4会优化成左移位，所以不需特意用移位运算，可以写出更可读的代码

**如果你在写大量浮点运算的程序，记住，Delphi不对浮点计算做优化。手工优化，必要时用汇编，或者考虑用C（不是C++）。

**with语句
with语句不止是源代码上的简洁，而且生成更快更短的代码。

**Delphi 6 的Alignment
Delphi 6 缺省按8字节对齐变量边界，在工程选项里将其改成4字节可以使生成的应用程序更短小。

**不要为Delphi里没有宏而抱怨
参数较少的函数，调用时只耗1到2个时钟周期（register调用协议的优势），因为没有参数压栈的开销。

 

 

Delphi代码优化（二） 整数篇

尽量使用32位变量

在32位代码中，32位变量是默认处理格式；16位变量（word，shortint，widechar）的运算会令处理器临时切换为16位处理模式，因而需要双倍的处理时间；相较之下，8位变量（byte，char）只要不与其它混用，却不会太慢。如果实在需要多次使用一个8或16位变量，可以考虑把它临时转换成32位变量，这只需要一步赋值：ADWord:=Aword;

避免使用子域类型
Pascal语言的一大优势便是其丰富的数据类型，Delphi之Object Pascal继承了这一传统，枚举和子域类型即属此类。但不幸的是，他们会为优化带来麻烦，因为它们的占用的字节数取决于其子域的大小。比如一个元素数不超过256个的枚举类型会占用1个字节，而例如MyYear=1900..2000则会占用两个字节，而如前文所述，16位变量是很慢的。

简化表达式
过于复杂的表达式会妨碍编译器的自动优化，这时可以考虑引入临时变量来化简表达式，这样可能（！）可以得以优化，更重要的是提高了代码的可读性。

不再畏惧乘法
PII出现以前，乘法运算是相当费时的，以至于当时的经典优化方法便是把一类特殊的乘法转变为移位运算和加法。而今，在作为标准配置的PII上，乘法和多数其它运算一样，只需要一个指令周期即可完成。当然Delphi编译器仍然会把诸如*2之类的运算优化为shl 1，这也不坏，不是吗？

临时子域类型
才揭过子域类型的短，又来说它的妙用:-p 但这也不是真正的子域类型，不过是形式上相似罢了。像以下的语句：
if ((x>=0) and (x=<10)) or ((x>=20) and (x<=30)) then …
可以改写为：
if x in [0..10,20..30] then …
子域数越多，优化效果越明显。不过除了在NOI题目里以外，天下可没有免费馅饼，这回的代价是占用一个临时寄存器。

movzx 与 xor/mov
这是读入小于32位数据的两种不同方法，后者在PII以前更具优势，而前者在PII上因其乱序执行的特性而显得更有效率。编译器对此的取舍规则似乎很复杂，必要时还是自己用嵌入汇编好了。

大整数运算
对付大整数（超过32位的），你有四种武器（为什么不是七种？问Borland，别来问我）——int64、comp、double和extended。其中除了64位整数类型int64外，其余都是浮点数，其运算都是由FPU指令实现的。这其中的comp类型，存储结构同int64一模一样，按照 Borland的官方说法，comp类型已经过时，应当被int64所取代，理由很简单——整数运算总比浮点快吧。然而根据一项在PII上进行的测试， int64除了在加减运算中具有无可比拟的优势外，在乘除方面，竟比浮点数还慢！

好在还有老当益壮的comp，只是稍有些繁琐。
首先将变量声明为int64，并声明两个辅助元：
var a,b,c,d,e: int64;
 ca:comp absolute a;
 cc:comp absolute c;
加减法不用变，除法就如下处理：
c:=trunc(ca/b); //is faster than c:= a div b
乘法这么来：
e:=round(ca*b+cc*d); //is faster than e:=a*b+c*d;

Delphi代码优化浮点篇
忘掉extended
  extended很大（10字节，如果代码对齐就有12字节），读写运算都很慢，是优化的大敌。且Delphi2-4对extended的代码对齐有bug。因此，若非必要，不要用extended。
  同时，在混合浮点类型的运算中，编译器为了不丢失精度，临时变量以extended类型存储，所以要避免混合浮点运算。
  还有，用const定义的常量，如不加指明，则也默认为extended类型。解决办法是，配合$J指示字，定义指明类型常量（typed constand）。

变FPU控制字
  默认的FPU控制字令除法运算和PII/PIII上的平方根运算慢而精确，当无须得到这样的结果时，可用Set8087CW让FPU“偷懒”。

对于Single类型:Set8087CW(Default8087CW and $FCFF)
对于Double类型:Set8087CW((Default8087CW and $FCFF) or $0200)
对于extended类型:Set8087CW(Default8087CW or $0300)

多用Round
  Trunc会读写FPU指令字，而Round不会，所以可以的话，尽量用Round。

传送实参
  对于返回浮点值的函数，入口和出口处会有附加的压栈退栈，对形如:
function func(x : SomeType): SomeFloat;
  不妨改写为:
procedure func(x : SomeType; var fp : SomeFloat);
  对于在过程中未修改的浮点形参，没必要用const修饰，因为那除了增加一个编译期检查外，别无用处。相应的对策是用var修饰为实参，强制传址。

自己动手，丰衣足食
  Delphi本身不对浮点运算作任何优化，因此很多时候，还得自己用汇编来解决。
  值得注意的是，Delphi中浮点异常的触发，不是在出错之后，而是在下一条浮点指令之前。因此，通常的作法是，在一次浮点操作完毕后，加一条FWAIT指令。

减少除法
  除法，即多次的减法，其代价是相当昂贵的，因而有必要减少除法的次数。
  另外，对于简单除法（如:a/5），编译器不一定（？！）会将其变为乘法（a*0.2），比如:
  fp:=fp*3*4/5+3*4/2;
  在Delphi 4中，会被编译为:
  fp:=fp*3*4/5+6;
  而只有:
  fp:=3*4/5*fp+3*4/2;
  才会被编译为:
  fp:=2.4*fp+6;
  鉴于编译器的繁复规则，建议这一步优化自己完成。

浮点零的检查

  检查一个浮点数是否为零，如果简单的“Afloat=0”，会把0转换为浮点零。而更好的办法是这样:
  对于Single类型:(Dword(pointer(Asingle))shl 1) =0
  对于Double类型:

type
  DoubleData=record lo,hi:Dword end;
Var
  ADouble:Double;
  Dd:DoubleData absolute Adouble;
begin
  …
  if ((dd.hi shl 1)+dd.lo)=0 then …
end;
  此法在PII上有30%-40%的效率提升。