模块尺寸优化

本文关注于使用VC编译器的编译选项来优化模块的尺寸，而“通过优化代码达到减少模块尺寸”(如通过DLL导出父类而在其他DLL中继承)是一个很复杂的命题，故不在本文的讨论范围内。

即使是使用VC编译器的编译选项来优化模块的尺寸，我们在实际使用过程中也不得不在“代码运行速率”“模块尺寸”和“安全性”三个方面进行权衡。因此，大致可以将这些编译选项分为三类：作为规范的(Criterion)，可选的(Optional)和不推荐(Not Recommend)。

 

 

[Criterion]

注：以下编译选项被应用后，是一定可以减少模块尺寸，且不会有安全性和性能上的问题，所以应该被程序员当作准则而被遵守。

 

1.       统一使用MD代替MT，即尽量使用动态链接CRT库的方式编译代码。

使用动态链接CRT库方式编译得到的模块将会依赖MSVCRT相关DLL，我们只需要将相应的MSVCRT库文件同时部署即可。另外，从Windows 98开始，系统会自带VC6.0版本对应的CRT库文件msvcrt.dll（但是如果在代码中使用标准C++库的某些函数后，模块将会依赖msvcp60.dll，这个DLL就必须由我们自己手动部署了）；而VC2005的再分发包则会在本地系统上部署VC2005对应的CRT库文件和C++库模块：msvcr80.dll和msvcp80.dll。总之，使用动态链接的方式编译出来模块的尺寸相对于静态编译，其减少量是相当可观的，而且不论是VC6.0还是VC2005，我们需要做的仅仅是考虑如何部署相关的MSVCRT库文件而已。

 

图1. VC6.0中设置“动态链接CRT库”编译选项(/MD)

 

图2. VC2005中设置“动态链接CRT库”编译选项(/MD)

 

       最后需要强调一点的是，VC6新建的DLL和EXE工程默认使用的都是静态链接CRT(/MT)方式，而VC2005则默认使用就是动态链接CRT(/MD)，所以在使用VC6进行开发的时候尤其要注意在发布之前需要手动修改这个编译选项，而VC2005则不需要(这恐怕就体现了编译器的进步吧)。

 

2.    不再为Windows 98做性能优化

VC在编译代码的时候，为了保证EXE或DLL在 Windows 98上的运行效率，默认会将“为Windows 98做性能优化”这个编译选项打开，其效果是会在生成模块的机器码的时候按照4KB边界进行对齐，这样做无疑会增加模块的冗余空间。

因此，如果我们的代码确定不再支持Windows 98或之前的操作系统的话（通常如此），就可以在编译器中关闭对Windows 98的性能优化。

 

在VC2005中关闭这个选项很方便：

图3. VC2005中关闭“为Windows 98优化”编译选项

 

而在VC6中，则需要在Linker选项页中手动添加编译参数(/OPT:NOWIN98)：

图4. VC6中关闭“为Windows 98优化”编译选项

 

3.    发布版本的模块不要再输入调试信息

       除非是用作本地或者远程调试的用途，否则不要在Release版本中添加调试信息，因为如果编译器插入调试信息，那么就会增加编译模块的尺寸。

      

图5. VC6.0中关闭“生成调试信息”编译选项

 

图6. VC2005中关闭“生成调试信息”编译选项

 

 

 

 

[Optional]

注：以下编译选项被应用后，一定可以减少尺寸但可能会存在风险或者性能上的问题。如果是涉及到性能上的损失，那么在对性能要求不甚敏感而对尺寸要求敏感的场合下，可酌情采用相关编译选项。

 

使用Minimize Size优化选项

使用这个编译选项后，编译出来的模块的尺寸减少量也是很可观的。这个选项的原理是，编译器将会通过重构机器码以减少文件尺寸。MSDN上有这样一个例子：

 

使用编译器编译下面的函数：

int differ(int x)

{

    return x * 71;

}

当出于大小考虑(/Os)编译时，编译器将返回语句中的乘法表达式显式实现为乘法，以产生短小但较慢的代码序列:

mov    eax, DWORD PTR _x$[ebp]

imul   eax, 71                  ; 00000047H

当出于速度考虑(/Ot)编译时，编译器将返回语句中的乘法表达式实现为一系列移位指令和 LEA 指令，以产生执行速度快但较长的代码序列：

mov    eax, DWORD PTR _x$[ebp]

mov    ecx, eax

shl    eax, 3

lea    eax, DWORD PTR [eax+eax*8]

sub    eax, ecx

 

从这段表述看来，Minmizie Size除了会影响EXE和DLL的加载速度之外，还会影响代码的运行速度。

 

但是我在实际实验中，发现VC2005在速度优先和尺寸优先两种情况下生成的汇编代码都是上述/注重尺寸的编译选项，并没有出现MSDN上提到的情况（莫非被微软忽悠了？）：

 

所以，在对代码运行速度特别敏感的场合，就不建议打开Minimize Size选项了，除非你认为模块尺寸的优先级高于代码运行速率。

 

图7. VC6.0中打开“Minimize Size”编译选项

 

图8. VC2005中打开“Minimize Size”编译选项

 

这里需要提醒大家一点的就是，VC发布时候编译的Release版本，其默认实际上使用的是Maximize Speed这种优化方式，而不是任何优化方式都没有使用的“纯”代码！

 

 

 

[Not Recommend]

注：以下的一些“非主流”的方法在一定程度上也可以减少模块尺寸，但是一般情况下，并不推荐使用。这里列举出来，稍微了解即可。

 

1.       使用第三方压缩工具

用第三方的打包压缩程序（如UPX）的确可以减少文件的尺寸，这些打包程序大多是通过压缩壳技术将PE文件中的数据段和代码段进行二进制级别的压缩，并且强制地再将机器码按照更小的边界尺寸进行对齐。首先我不敢确定这样会不会同样影响代码的运行速度，即使不会影响，恐怕也会存在代码跟踪的问题吧。

 

 

2.       自定义对齐边界

此方法只在VC6中有效。即由程序员自己定义段对齐边界(Section Align Boundary)：

 

#pragma comment(linker, "/FILEALIGN:16")

#pragma comment(linker, "/ALIGN:16")

 

然而即使是在VC6中，个人也强烈不推荐使用这种方法，因为经过实验我发现，对于EXE来说，这种方法可能还能奏效，但是对于DLL来说，可能由于压缩了DLL的某些段，有可能导致LoadLibrary的时候，Windows无法将当前的DLL识别成为一个合法的Win32 PE文件，从而导致加载失败。

 

 

3.       修改模块入口函数

不管是EXE还是DLL，其程序入口都不是我们认为的那样。对于EXE，并不是从WinMain进入的；对于DLL，也不是从DllMain进入的。Windows在加载EXE或者DLL的时候，首先会做大量的初始化工作，如CRT库的初始化，生成全局类对象和初始化静态变量，自定义的异常处理等等。所以可能最先运行的函数是C Runtime Libray中的_mainCRTStartup 或者_WinMainCRTStartup函数。

然而有时候我们实现的某个模块可能只是一个功能性的模块（例如计算两个矩阵相加的结果），就没有必要进行CRT库的初始化，并且这个模块中并没有类似全局类或者静态变量的定义，

那么我们就完全可以自己制定本模块的EntryPoint为WinMain或者DllMain等等。

经过这样的操作，也可以在一定程度上减少模块尺寸。但是，由于剑走偏锋，实际中也不推荐使用。

 

图9. VC6.0中设置入口函数

 

图10. VC2005中设置入口函数