C程序优化之路
2007-12-11 00:28
190 查看
C程序优化之路
本文摘自游戏变成开发文章。
本文讲述在编写C程序代码的常用优化办法，分为I/O篇，内存篇，算法篇，MMX汇编篇。
一．I/O篇
如果有文件读写的话，那么对文件的访问将是影响程序运行速度的一大因素。提高文件访问速度的主要办法有两个：一是采用内存映射文件，二是使用内存缓冲。下面是一组测试数据（见《UNIX环境高级编程》3.9节），显示了用18种不同的缓存长度，读1 468 802字节文件所得到的结果。
缓冲大小用户CPU（秒）系统CPU（秒）时钟时间（秒）循环次数（秒）
123.8397.9423.41 468 802
212.3202.0215.2734 401
46.1100.6107.2367 201
83.050.754.0183 601
161.525.327.091 801
320.712.813.745 901
640.36.67.022 951
1280.23.33.611 476
2560.11.81.95 738
5120.01.01.12 869
1 0240.00.60.61 435
2 0480.00.40.4718
4 0960.00.40.4359
8 1920.00.30.3180
16 3840.00.30.390
32 7680.00.30.345
65 5360.00.30.323
131 0720.00.30.312
可见，一般的当内存缓冲区大小为8192的时候，性能就已经是最佳的了，这也就是为什么在H.263等图像编码程序中，缓冲区大小为8192的原因（有的时候也取2048大小）。使用内存缓冲区方法的好处主要是便于移植，占用内存少，便于硬件实现等。下面是读取文件的C伪码：
int Len;
BYTE buffer[8192];
ASSERT(buffer==NULL);
If buffer is empty{
Len=read(File,ld->rdbfr,8192);
If(len==0) No data and exit;
}
但是如果内存比较大的时候，采用内存映射文件可以达到更佳性能，并且编程实现简单。内存映射的具体使用说明见msdn October 2001中的Platform SDK
Documentation—Base Services—File Storage—File Mapping。下面是一点建议：
① 内存映射文件不能超过虚拟内存的大小，最好也不要太大，如果内存映射文件接近虚拟内存大小的时候，反而会大大降低程序的速度（其实是因为虚拟内存不足导致系统运行效率降低），这个时候，可以考虑分块映射，但是我觉得如果这样，还不如直接使用内存缓冲来得直接一些。
② 可以将两种方法统一使用，如我在编大图像文件数据处理的时候（因为是Unix工作站，内存很大GB单位）使用了内存映射文件，但是为了最佳性能，也使用了一行图像缓存，这样在读取文件中数据的时候，就保证了仅仅是顺序读写（内存映射文件中，对顺序读写有专门的优化）。
③ 在写文件的时候使用内存映射文件要有一点小技巧：应该先创建足够大的文件，然后将这个文件映射，在处理完这个文件的时候，用函数SetFilePointer和SetEndOfFile来对文件进行截尾。
④ 对内存映射文件进行操作与对内存进行操作类似（使用起来就象数组一样），那么如果有大块数据读写的时候，切记使用memcpy（）函数（或者CopyMemory（）函数）
总之，如果要使用内存映射文件，必须：1.处理的文件比较的小，2.处理的文件很大，但是运行环境内存也很大，并且一般在运行该程序的时候不运行其他消耗内存大的程序，同时用户对速度有特别的要求，而且对内存占用没有什么要求。如果以上两个条件不满足的时候，建议使用内存缓冲区的办法。
二．内存篇
在上一篇中我们讲述了如何优化文件的读写，这一篇则主要讲述对内存操作的优化，主要有数组的寻址，指针链表等，还有一些实用技巧。
I．优化数组的寻址
在编写程序时，我们常常使用一个一维数组a[M×N]来模拟二维数组a
[M]，这个时候访问a[]一维数组的时候：我们经常是这样写a[j×M＋i]（对于a[j][i]）。这样写当然是无可置疑的，但是显然每个寻址语句j×M＋i都要进行一次乘法运算。现在再让我们看看二维数值的寻址，说到这里我们不得不深入到C编译器在申请二维数组和一维数组的内部细节上――实际在申请二位数组和一维数组，编译器的处理是不一样的，申请一个a
[M]的数组要比申请一个a[M×N]的数组占用的空间大！二维数组的结构是分为两部分的：
① 是一个指针数组，存储的是每一行的起始地址，这也就是为什么在a
[M]中，a[j]是一个指针而不是a[j][0]数据的原因。
② 是真正的M×N的连续数据块，这解释了为什么一个二维数组可以象一维数组那样寻址的原因。（即a[j][i]等同于(a[0])[j×M＋i]）
清楚了这些，我们就可以知道二维数组要比（模拟该二维数组的）一维数组寻址效率高。因为a[j][i]的寻址仅仅是访问指针数组得到j行的地址，然后再+i,是没有乘法运算的！
所以，在处理一维数组的时候，我们常常采用下面的优化办法：（伪码例子）
int a[M*N];
int *b=a;
for(…)
{
b[…]=…;
…………
b[…]=…;
b+=M;
}
这个是遍历访问数组的一个优化例子，每次b+=M就使得b更新为下一行的头指针。当然如果你愿意的话，可以自己定义一个数组指针来存储每一行的起始地址。然后按照二维数组的寻址办法来处理一维数组。不过，在这里我建议你干脆就直接申请一个二维数组比较的好。下面是动态申请和释放一个二维数组的C代码。
int get_mem2Dint(int ***array2D, int rows, int columns) //h.263源代码
{
int i;
if((*array2D = (int**)calloc(rows, sizeof(int*))) == NULL) no_mem_exit(1);
if(((*array2D)[0] = (int* )calloc(rows*columns,sizeof(int ))) == NULL) no_mem_exit(1);
for(i=1 ; i>1这个是常用的方法，不过要注意的是这两个不是完全等价的！因为：如果n＝3的话，n/2=1;n>>1=1;但是，如果n＝-3的话，n/2=-1;n>>1=-2所以说在正数的时候，他们都是向下取整，但是负数的时候就不一样了。（在JPG2000中的整数YUV到RGB变换一定要使用>>来代替除法就是这个道理）
② 还有就是a=a+1要写为a++; a=a+b要写为a+=b（估计一般用VB的才会写a=a+1 :P）
③ 将多种运算融合：比如a[i++];就是先访问a[i]，再令i加1；从汇编的角度上说，这个确实是优化的，如果写为a[i]，和i++的话，有可能就会有两次的对i变量的读，一次写（具体要看编译器的优化能力了），但是如果a[i++]的话，就一定只读写i变量一次。不过这里有一个问题要注意：在条件判断内的融合一定要小心，比如：（idct变换中的0块判断，陈王算法）
if (!((x1 = (blk[8*4]<<8)) | (x2 = blk[8*6]) | (x3 = blk[8*2]) | (x4 = blk[8*1]) | (x5 = blk[8*7]) | (x6 = blk[8*5]) | (x7 = blk[8*3])))
在条件判断中融合了赋值语句，但是实际上如果条件为真的话，是不需要这些赋值语句的，也就是说当条件真的时候，多了一些垃圾语句，这些是在h263源码上的问题，虽然这些垃圾语句使得计算0块的时候，时间增加了30％，但是由于idct仅仅占1%的时间，0块又仅仅30%~70%的时间，所以这些性能损失是没有什么关系的。（这是后来我用汇编改写源码的时候得到的结论）。这里也说明了，程序优化一定重点在最耗时的地方。对于不耗时的代码优化是没有太大的实用意义的。
II．以内存换速度：
天下总是难有双得的事情，编程也是一样，大多数情况，速度同内存（或者是性能，比如说压缩性能什么的）是不可兼得的。目前程序加速的常用算法一个大方面就是利用查表来避免计算（比如在jpg有huffman码表，在YUV到RGB变换也有变换表）这样原来的复杂计算现在仅仅查表就可以了，虽然浪费了内存，不过速度显著提升，还是很划算的。在数据库查询里面也有这样的思想，将热点存储起来以加速查询。 现在介绍一个简单的例子，（临时想的，呵呵）：比如，在程序中要经常（一定要是经常！）计算1000到2000的阶乘，那么我们可以使用一个数组a[1000]先把这些值算好，保留下来，以后要计算1200！的时候，查表a[1200-1000]就可以了。
III．化零为整
由于零散的内存分配，以及大量小对象建立耗时很大，所以对它们的优化有时会很有效果，比如上一篇我说的链表存在的问题，就是因为大量的零散内存分配。现在就从一个vb的程序说起，以前我用vb给别人编小程序的时候，（呵呵，主要是用vb编程比vc快，半天就可以写一个）在使用MSFlexGrid控件的时候（就是一个表格控件），发现如果一行一行的增加新行，刷新速度十分的慢，所以我就每次增加100行，等到数据多到再加新行的时候，再加100行，这样就“化零为整”了，使用这样的方法，刷新的速度比原来快了n倍！其实这样的思想应用很多，如：程序运行的时候，其实就占用了一定的空间，后来的小块内存分配是先在这个空间上的，这就保证了内存碎片尽可能的少，同时加快运行速度。
IV．条件语句或者case语句将最有可能的放在前面
优化效果不明显。想得到就用吧，想不到就算了。
V．为了程序的可读性，不去做那些编译器可以做的或者优化不明显的处理：
这个是很重要的，一个普通程序的好坏，主要是它的可读性，可移植性，可重用性，然后才是它的性能。所以，如果编译器本身可以帮助我们优化的话，我们就没有必要写那些大家都不怎么看得懂的东西。比如a＝52（结束）－16（起始）；这样写可能是因为在别人读程序的时候，一下就明白了a的含义。我们不用写为a＝36，因为编译器是会帮我们算出来的。
IV．具体情况具体分析：
具体情况具体分析，这是放之四海而皆准的真理。没有具体的分析，就不能针对问题灵活应用解决的办法。下面我就说说分析的方法。即如何找到程序的耗时点：（从最简单的办法说起，先说明一个函数GetTickCount(),这个函数在头尾各调用一次，返回值相减就是程序的耗时，精确到1ms）
① 对于认为是比较耗时的函数，运行两次，或者将函数内部的语句注释掉（要保证程序可以运行），看看多（或者少了）多少时间。这个办法简单不精确。
② 每个地方都用GetTickCount()函数测试时间，注意GetTickCount()只能精确到ms。一般的小于10ms就不太精确了。
③ 使用另外一个函数QueryPerformanceCounter（&Counter）和QueryPerformanceFrequency(&Frequency)，前面计算cpu时钟周期，后面是cpu频率相除就是时间。不过如果你要精确到这一步的话，建议将进程设置为最高级别，防止它被阻塞。
最后讲讲我处理的一个程序：程序要求我忘了，反正里面有一个函数，函数里面有一个大的循环，循环内部的处理比较耗时。结果最初程序表现出来的状况是开始还很快，越到后面越慢；我在跟踪程序中变量的时候，发现最初的循环在循环几次后就跳出了，而后面的循环次数越来越多。找到了为什么慢的原因，就可以对症下药了，我的处理是每次循环不是从头开始，而是从上一次循环跳出的地方开始左右循环（因为可能下一次循环跳出的地方别上一次的小，所以也要遍历前面的），这样程序的速度在后面也很快了。我讲这个的道理就是在实际运用中，要具体的分析程序慢的真正原因，才能达到最佳的优化效果。
本文转自
http://g6a71.mail.163.com/a/s?func=mbox:readMessageHTML&sid=nBtoPWddiDAqLWQFbJddFKQDolCowJLd&mid=8:1tbiSgEfLEIFvkrWcAAAst
本文摘自游戏变成开发文章。
本文讲述在编写C程序代码的常用优化办法，分为I/O篇，内存篇，算法篇，MMX汇编篇。
一．I/O篇
如果有文件读写的话，那么对文件的访问将是影响程序运行速度的一大因素。提高文件访问速度的主要办法有两个：一是采用内存映射文件，二是使用内存缓冲。下面是一组测试数据（见《UNIX环境高级编程》3.9节），显示了用18种不同的缓存长度，读1 468 802字节文件所得到的结果。
缓冲大小用户CPU（秒）系统CPU（秒）时钟时间（秒）循环次数（秒）
123.8397.9423.41 468 802
212.3202.0215.2734 401
46.1100.6107.2367 201
83.050.754.0183 601
161.525.327.091 801
320.712.813.745 901
640.36.67.022 951
1280.23.33.611 476
2560.11.81.95 738
5120.01.01.12 869
1 0240.00.60.61 435
2 0480.00.40.4718
4 0960.00.40.4359
8 1920.00.30.3180
16 3840.00.30.390
32 7680.00.30.345
65 5360.00.30.323
131 0720.00.30.312
可见，一般的当内存缓冲区大小为8192的时候，性能就已经是最佳的了，这也就是为什么在H.263等图像编码程序中，缓冲区大小为8192的原因（有的时候也取2048大小）。使用内存缓冲区方法的好处主要是便于移植，占用内存少，便于硬件实现等。下面是读取文件的C伪码：
int Len;
BYTE buffer[8192];
ASSERT(buffer==NULL);
If buffer is empty{
Len=read(File,ld->rdbfr,8192);
If(len==0) No data and exit;
}
但是如果内存比较大的时候，采用内存映射文件可以达到更佳性能，并且编程实现简单。内存映射的具体使用说明见msdn October 2001中的Platform SDK
Documentation—Base Services—File Storage—File Mapping。下面是一点建议：
① 内存映射文件不能超过虚拟内存的大小，最好也不要太大，如果内存映射文件接近虚拟内存大小的时候，反而会大大降低程序的速度（其实是因为虚拟内存不足导致系统运行效率降低），这个时候，可以考虑分块映射，但是我觉得如果这样，还不如直接使用内存缓冲来得直接一些。
② 可以将两种方法统一使用，如我在编大图像文件数据处理的时候（因为是Unix工作站，内存很大GB单位）使用了内存映射文件，但是为了最佳性能，也使用了一行图像缓存，这样在读取文件中数据的时候，就保证了仅仅是顺序读写（内存映射文件中，对顺序读写有专门的优化）。
③ 在写文件的时候使用内存映射文件要有一点小技巧：应该先创建足够大的文件，然后将这个文件映射，在处理完这个文件的时候，用函数SetFilePointer和SetEndOfFile来对文件进行截尾。
④ 对内存映射文件进行操作与对内存进行操作类似（使用起来就象数组一样），那么如果有大块数据读写的时候，切记使用memcpy（）函数（或者CopyMemory（）函数）
总之，如果要使用内存映射文件，必须：1.处理的文件比较的小，2.处理的文件很大，但是运行环境内存也很大，并且一般在运行该程序的时候不运行其他消耗内存大的程序，同时用户对速度有特别的要求，而且对内存占用没有什么要求。如果以上两个条件不满足的时候，建议使用内存缓冲区的办法。
二．内存篇
在上一篇中我们讲述了如何优化文件的读写，这一篇则主要讲述对内存操作的优化，主要有数组的寻址，指针链表等，还有一些实用技巧。
I．优化数组的寻址
在编写程序时，我们常常使用一个一维数组a[M×N]来模拟二维数组a
[M]，这个时候访问a[]一维数组的时候：我们经常是这样写a[j×M＋i]（对于a[j][i]）。这样写当然是无可置疑的，但是显然每个寻址语句j×M＋i都要进行一次乘法运算。现在再让我们看看二维数值的寻址，说到这里我们不得不深入到C编译器在申请二维数组和一维数组的内部细节上――实际在申请二位数组和一维数组，编译器的处理是不一样的，申请一个a
[M]的数组要比申请一个a[M×N]的数组占用的空间大！二维数组的结构是分为两部分的：
① 是一个指针数组，存储的是每一行的起始地址，这也就是为什么在a
[M]中，a[j]是一个指针而不是a[j][0]数据的原因。
② 是真正的M×N的连续数据块，这解释了为什么一个二维数组可以象一维数组那样寻址的原因。（即a[j][i]等同于(a[0])[j×M＋i]）
清楚了这些，我们就可以知道二维数组要比（模拟该二维数组的）一维数组寻址效率高。因为a[j][i]的寻址仅仅是访问指针数组得到j行的地址，然后再+i,是没有乘法运算的！
所以，在处理一维数组的时候，我们常常采用下面的优化办法：（伪码例子）
int a[M*N];
int *b=a;
for(…)
{
b[…]=…;
…………
b[…]=…;
b+=M;
}
这个是遍历访问数组的一个优化例子，每次b+=M就使得b更新为下一行的头指针。当然如果你愿意的话，可以自己定义一个数组指针来存储每一行的起始地址。然后按照二维数组的寻址办法来处理一维数组。不过，在这里我建议你干脆就直接申请一个二维数组比较的好。下面是动态申请和释放一个二维数组的C代码。
int get_mem2Dint(int ***array2D, int rows, int columns) //h.263源代码
{
int i;
if((*array2D = (int**)calloc(rows, sizeof(int*))) == NULL) no_mem_exit(1);
if(((*array2D)[0] = (int* )calloc(rows*columns,sizeof(int ))) == NULL) no_mem_exit(1);
for(i=1 ; i>1这个是常用的方法，不过要注意的是这两个不是完全等价的！因为：如果n＝3的话，n/2=1;n>>1=1;但是，如果n＝-3的话，n/2=-1;n>>1=-2所以说在正数的时候，他们都是向下取整，但是负数的时候就不一样了。（在JPG2000中的整数YUV到RGB变换一定要使用>>来代替除法就是这个道理）
② 还有就是a=a+1要写为a++; a=a+b要写为a+=b（估计一般用VB的才会写a=a+1 :P）
③ 将多种运算融合：比如a[i++];就是先访问a[i]，再令i加1；从汇编的角度上说，这个确实是优化的，如果写为a[i]，和i++的话，有可能就会有两次的对i变量的读，一次写（具体要看编译器的优化能力了），但是如果a[i++]的话，就一定只读写i变量一次。不过这里有一个问题要注意：在条件判断内的融合一定要小心，比如：（idct变换中的0块判断，陈王算法）
if (!((x1 = (blk[8*4]<<8)) | (x2 = blk[8*6]) | (x3 = blk[8*2]) | (x4 = blk[8*1]) | (x5 = blk[8*7]) | (x6 = blk[8*5]) | (x7 = blk[8*3])))
在条件判断中融合了赋值语句，但是实际上如果条件为真的话，是不需要这些赋值语句的，也就是说当条件真的时候，多了一些垃圾语句，这些是在h263源码上的问题，虽然这些垃圾语句使得计算0块的时候，时间增加了30％，但是由于idct仅仅占1%的时间，0块又仅仅30%~70%的时间，所以这些性能损失是没有什么关系的。（这是后来我用汇编改写源码的时候得到的结论）。这里也说明了，程序优化一定重点在最耗时的地方。对于不耗时的代码优化是没有太大的实用意义的。
II．以内存换速度：
天下总是难有双得的事情，编程也是一样，大多数情况，速度同内存（或者是性能，比如说压缩性能什么的）是不可兼得的。目前程序加速的常用算法一个大方面就是利用查表来避免计算（比如在jpg有huffman码表，在YUV到RGB变换也有变换表）这样原来的复杂计算现在仅仅查表就可以了，虽然浪费了内存，不过速度显著提升，还是很划算的。在数据库查询里面也有这样的思想，将热点存储起来以加速查询。 现在介绍一个简单的例子，（临时想的，呵呵）：比如，在程序中要经常（一定要是经常！）计算1000到2000的阶乘，那么我们可以使用一个数组a[1000]先把这些值算好，保留下来，以后要计算1200！的时候，查表a[1200-1000]就可以了。
III．化零为整
由于零散的内存分配，以及大量小对象建立耗时很大，所以对它们的优化有时会很有效果，比如上一篇我说的链表存在的问题，就是因为大量的零散内存分配。现在就从一个vb的程序说起，以前我用vb给别人编小程序的时候，（呵呵，主要是用vb编程比vc快，半天就可以写一个）在使用MSFlexGrid控件的时候（就是一个表格控件），发现如果一行一行的增加新行，刷新速度十分的慢，所以我就每次增加100行，等到数据多到再加新行的时候，再加100行，这样就“化零为整”了，使用这样的方法，刷新的速度比原来快了n倍！其实这样的思想应用很多，如：程序运行的时候，其实就占用了一定的空间，后来的小块内存分配是先在这个空间上的，这就保证了内存碎片尽可能的少，同时加快运行速度。
IV．条件语句或者case语句将最有可能的放在前面
优化效果不明显。想得到就用吧，想不到就算了。
V．为了程序的可读性，不去做那些编译器可以做的或者优化不明显的处理：
这个是很重要的，一个普通程序的好坏，主要是它的可读性，可移植性，可重用性，然后才是它的性能。所以，如果编译器本身可以帮助我们优化的话，我们就没有必要写那些大家都不怎么看得懂的东西。比如a＝52（结束）－16（起始）；这样写可能是因为在别人读程序的时候，一下就明白了a的含义。我们不用写为a＝36，因为编译器是会帮我们算出来的。
IV．具体情况具体分析：
具体情况具体分析，这是放之四海而皆准的真理。没有具体的分析，就不能针对问题灵活应用解决的办法。下面我就说说分析的方法。即如何找到程序的耗时点：（从最简单的办法说起，先说明一个函数GetTickCount(),这个函数在头尾各调用一次，返回值相减就是程序的耗时，精确到1ms）
① 对于认为是比较耗时的函数，运行两次，或者将函数内部的语句注释掉（要保证程序可以运行），看看多（或者少了）多少时间。这个办法简单不精确。
② 每个地方都用GetTickCount()函数测试时间，注意GetTickCount()只能精确到ms。一般的小于10ms就不太精确了。
③ 使用另外一个函数QueryPerformanceCounter（&Counter）和QueryPerformanceFrequency(&Frequency)，前面计算cpu时钟周期，后面是cpu频率相除就是时间。不过如果你要精确到这一步的话，建议将进程设置为最高级别，防止它被阻塞。
最后讲讲我处理的一个程序：程序要求我忘了，反正里面有一个函数，函数里面有一个大的循环，循环内部的处理比较耗时。结果最初程序表现出来的状况是开始还很快，越到后面越慢；我在跟踪程序中变量的时候，发现最初的循环在循环几次后就跳出了，而后面的循环次数越来越多。找到了为什么慢的原因，就可以对症下药了，我的处理是每次循环不是从头开始，而是从上一次循环跳出的地方开始左右循环（因为可能下一次循环跳出的地方别上一次的小，所以也要遍历前面的），这样程序的速度在后面也很快了。我讲这个的道理就是在实际运用中，要具体的分析程序慢的真正原因，才能达到最佳的优化效果。
本文转自
http://g6a71.mail.163.com/a/s?func=mbox:readMessageHTML&sid=nBtoPWddiDAqLWQFbJddFKQDolCowJLd&mid=8:1tbiSgEfLEIFvkrWcAAAst
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 