条件与分裂

Question

鉴于以下声明执行了很多:

iNormVal = iVal / uRatio;

如果uRatio == 1大多数(90%)的时间,以下会更有意义(表现明智)吗？

if(uRatio > 1)
iNormVal = iVal / uRatio;
else
iNormVal = iVal;

谢谢..

Answer 1

由于您发现这是一个潜在的瓶颈,因此这个位置很可能与您的应用程序的整体速度完全无关.说真的,人类,甚至是大师程序员,都非常不善于发现真正的瓶颈.(不同的是,优秀的程序员承认并宣传这一点,而大三学生则花时间来优化不相关的点.)

通常我发现这种优化方法最有帮助:

1. 如果速度是主要问题,请在发布应用程序之前安排大量时间进行优化.
2. 设计您的代码,使其不会产生固有的悲观情绪.
3. 以最容易理解代码的方式实现它.防止明显的悲观化(比如通过值而不是引用传递参数),但不要过度兴奋.
4. 检查它是否太慢.如果是这样,应用程序的概述和识别热点.
5. 将资源放入优化(从而可能混淆)这些热点,迭代分析以检查哪些更改有所帮助.
6. 当应用程序足够快时停止.

(显然,这对于库代码来说是不同的,但是这几个步骤对你来说会有很长的路要走.)

Answer 2

您需要对此进行分析才能进行测量，这很难猜测。编译器可能会认为您错了并删除测试，因此请检查是否进行优化。

（整数）除法的实际成本可能相当低，尤其是在现代桌面级处理器上。根据此 PDF，现代（Wolfdale/Nehalem/Sandy Bridge）32/32 位除法的成本分别为 14-23/17-28/20-28 个周期。所以，如果你真的经常这样做，它可能会增加。在这种情况下，如果可能的话，请考虑并行（矢量化）选项。

如果可能的话，我会尽量避免它，因为它引入了一个分支。分支有两个缺点：它们引入了阅读代码的程序员必须理解的多个路径，从而使代码变得更加复杂，并且它们还可能引入执行开销。