关于C代码性能调优的简单思考

 

在项目中要对项目的性能进行测试和优化。因所用的AIX平台不能使用purify。所以只能手工对代码进行测试。目前采用了两个自定义的函数简单实现如下：

/************************************************************************/

class CTools

{

public:

    。。。。。。。。。。。。。。。。。。。。。。。。。

/*获取时间差的开始时间函数*/

    static struct timeval getTimeBegin(void);

    /*获取时间差*/

static double getTimeInter(struct timeval timeBegin);

。。。。。。。。。。。。。。。。。。。。。。。。。

};

/***********************************************************************/

/*获取时间差的开始时间函数*/

struct timeval CTools::getTimeBegin(void)

{

           struct timeval timeBegin;

           gettimeofday(&timeBegin,NULL);

           return timeBegin;

}

/*获取时间差*/

double CTools::getTimeInter(struct timeval timeBegin)

{

        double timeInter;

        struct timeval timeEnd;

        gettimeofday(&timeEnd,NULL);

           timeInter = 1000000*(timeEnd.tv_sec - timeBegin.tv_sec) + timeEnd.tv_usec - timeBegin.tv_usec;

        timeInter /= 1000000;

        return timeInter;

}

/**************************************************************************/

虽然方法很笨。但对项目的性能还是可以看出那里的代码影响大的。现将我的简单性能测试建议贴出：

1． 将原子函数有多个实参的在一个for循环里得出所有的实参。

例如：checkproduct 经测试，对settleSubsExpense影响很大。

2． 对项目中不是动态调用原子函数的顺序进行调整。因为原子函数互相之间是平级的校验。如果把复杂的原子函数放后面。对整体性能有一定的影响。

3． 14个项目中检查下是否还包含提交数据库语句的。因为在项目中不必提交。在 settleYdxj中还有提交。是多余的。Commit对多进程来说引起锁的概率很大。所以设计了批量提交。

4． 顺便检查下自己的代码errMsg是不是你自己要打印的东西。不要打印的东西不是你自己要打印的东西

现对我的建议分析如下。对我们日常的编程影响如下：

1． 在将一个很大的函数分解成多个函数的时候。虽然对于模块化思想是对的。在考虑高内聚低偶合的情况下。要思考这个函数在整个框架中使用是否频繁。如果很频繁。就要考虑他的效率。在上面的测试性能的第一条中。就是在一个原子函数中for(;;)查找实参。就是因为把几个实参分成几个小函数。一个函数完成一个实参的校验工作。这样在每个小函数里就每次都校验。这样很好理解。但从总体上就for(;;)多跑了几次。在微秒级别就显得很大。所以建议一次for(;;)里。把所有实参都记录。查找出。这样在校验的时候。直接定位校验。效率我想会快几倍。

2． 对于这条。先看如下例子：

for(;;)

   {

         if((1)||(2))

          break;

}

如果在业务中if的条件1和2是等价的。而且成立的机会均等。请把简单的放前面。因为概率相等。是不是效率会高点啊。

3． 如同走路。你不知道你将去那里。为什么要走。做软件。不知道设计是啥。为啥去编码。

编码一定要严格遵守设计。变动请填单。谈点实在的东西：在多进程并发的时候，原本设计在父进程里一次连接数据库。在子进程里能继承下去。但好象并发的时候锁的概率太大。后来就在每个进程里单独连接数据库。而且是批量提交。本来还想设计把每次update的所有值先保存到一个数组里。这样就会更加避免锁的概率。但因为业务方面的原因。那样实现难度比较大。所以放弃了。

4． 写代码要用心。