Pointers on C——8 Arrays.7

来源:互联网 发布:35是不是质数的算法 编辑:程序博客网 时间:2024/06/07 10:44

Conclusions

What can we learn from these experiments?

我们可以从这些试验中学到什么呢?


1. Pointer variables can result in more efficient code than subscripts when you are moving through an array by some fixed increment. This point is especially true when the increment is one and the machine has an autoincrement addressing mode.

1.当你根据某个固定数目的增量在一个数组中移动时,使用指针变量将比使用下标产生效率更高的代码。当这个增量是1 并且机器具有地址自动增量模型时,这点表现得更为突出。


2. Pointers declared as register variables are often more efficient than pointers in static memory or on the stack (the amount of improvement depends on the particular machine youʹre working with).

2. 声明为寄存器变量的指针通常比位于静态内存和堆栈中的指针效率更高(具体提高的幅度取决于你所使用的机器)。


3. If you can check for loop termination by testing something that is already being initialized and adjusted for the loop, then you donʹt need a separate counter.

3. 如果你可以通过测试一些已经初始化并经过调整的内容来判断循环是否应该终止,那么你就不需要使用一个单独的计数器。


4. Expressions that must be evaluated at run time are more expensive than constant expressions such as &array[SIZE] or array + SIZE.

4. 那些必须在运行时求值的表达式较之诸如&array[SIZE] 或array+SIZE 这样的常量表达式往往代价更高。


The previous examples must now be put into perspective. Is it worth replacing the first loop, which is easily understood, with the last one, which one reader called ʺotter gibberish,ʺ just to save a few dozen microseconds of execution time? Occasionally yes, but in most cases the answer is definitely not! The cost of gaining runtime efficiency in this way is to make the program more difficult to write in the first place and more difficult to maintain later. If the program doesnʹt work or cannot be maintained, its execution speed is irrelevant.

现在,我们必须对前面这些例子进行综合评价。仅仅为了几十微秒的执行时间,是不是值得把第1 个非常容易理解的循环替换成最后一个被某读者称为"莫名其妙"的循环呢?偶尔,答案是肯定的。但在绝大多数情况下,答案是不容直疑的"否"。在这种方法中,为了一点点运行时效率,它所付出的代价是:程序难于编写在前,难于维护在后。如果程序无法运行或者无法维护,它的执行速度再快也无济于事。


It is easy to argue that experienced C programmers will have little trouble with the pointer loop, but there are two fallacies to this argument. First, ʺlittle troubleʺ actually means ʺsome trouble.ʺ Using complex idioms naturally involves more risk than using simple ones. Second, the maintenance programmers who work on the code later may not be as experienced as you are. Program maintenance is the major cost of a software product, so programming techniques that make maintenance more difficult must be used with care.

你很容易争辩说,经验丰富的C 程序员在使用指针循环时不会遇到太大麻烦。但这个论断存在两个荒谬之处。首先, "不会遇到太大麻烦"实际上意味着"还是会遇到一些麻烦"。从本质上说,复杂的用法比简单的用法所涉及的风险要大得多。其次,维护代码的程序员可能并不如阁下经验丰富。程序维护是软件产品的主要成本所在,所以那些使程序维护工作更为困难的编程技巧应慎重使用。


Also, some machines are designed with specific instructions to perform array subscripting, with the intent of making this common operation very fast. A compiler for such a machine will implement subscript expressions with these specialized instructions but may not use them to implement pointer expressions, even though it should. On such a machine, then, a subscript may indeed be more efficient than a pointer.

同时,有些机器在设计时使用了特殊的指令,用于执行数组下标操作,目的就是为了使这种极为常用的操作更加快速。在这种机器上的编译器将使用这些特殊的指令来实现下标表达式,但编译器并不一定会用这些指令来实现指针表达式,即使后者也应该这样使用。这样,在这种机器上,下标可能比指针效率更高。


Then what is the point of these experiments with efficiency? You may have to read some ʹʺgibberishʺ that someone else wrote, so it is important that you understand it. But there are also a few places where peak efficiency is vital, such as real‐time programs that must respond quickly to events as they occur. But any program that is too slow can benefit from these techniques. The key is to identify the sections of code that are taking the most time and concentrate your energies on improving them, for that is how you achieve the biggest gains for your effort. Techniques for identifying these sections of code are discussed in Chapter 18.

那么,比较这些试验的效率又有什么意义呢?你可能被迫阅读一些别人所编写的"莫名其妙"的代码,所以理解这类代码还是非常重要的。而且在某些场合,追求峰值效率是至关重要的,如那些必须对即时发生的事件作出最快反应的实时程序。但那些运行速度过于缓慢的程序也可以从这类技巧中获益。关键是你先要确认程序中哪些代码段占用了绝大部分运行时间,然后再把你的精力集中在这些代码上,致力于改进它们。这样,你的努力才会获得最大的收获。用于确认这类代码段的技巧将在第18 章讨论。


上一章 Pointers on C——8 Arrays.6

原创粉丝点击