Wha*_*ing 11 c++ optimization premature-optimization micro-optimization
有点奇怪的是:我刚才有一位朋友告诉我重新安排这个示例for循环:
for(int i = 0; i < constant; ++i) {
// code...
}
至:
for(int i = 0; constant > i; ++i) {
// code...
}
会略微提高C++的性能.我没有看到如何将常量值与变量进行比较比反之亦然,并且我运行的一些基本测试没有显示两种实现之间的速度差异.测试这个Python while循环也是如此:
while i < constant:
# code...
i += 1
VS:
while constant > i:
# code...
i += 1
我错了吗？我的简单测试不足以确定速度变化吗？这是否适用于其他语言？或者这只是一个新的最佳实践？
cha*_*aos 45
它更多地属于C++民间传说,手工微优化,在特定版本的特定编译器上运行一次,并且随着某种传说将拥有者与普通群体区分开来,传递下去.这是垃圾.剖析是事实.
Jar*_*Par 10
我的怀疑是你的朋友100%错了.但我不相信我的意见,而不是相信你的朋友.事实上,如果存在性能问题,那么只有一个人应该信任.
这是只有你能永远与一个办法是或不是比其他任何快权力要求的方式.
您给出的示例在C++中应该完全没有性能差异,我怀疑它们在Python中也会有所不同.
也许你会将它与不同的优化混淆:
for (int i = 0; i < variable; ++i)
// ...vs...
for (int i = variable; i ; --i)
后者在某些体系结构中更快,因为递减变量的行为将设置零标志,然后可以在跳转 - 如果不是零指令中检查,从而为您提供循环迭代和条件.前一个示例需要执行显式比较或减法来设置标志,然后基于此跳转.
但是,大多数情况下,编译器可以将第一种情况优化为第二种情况(特别是如果它看到变量实际上是常量),并且在某些编译器/体系结构组合上可能会生成使第一种方法更像第二种情况的指令.这样的事情只值得尝试,如果你有一个内部循环,你的探查器告诉你是昂贵的,但你永远不会注意到差异,如果有一个.
假设进行短路评估,那么唯一一次应该产生很大差异的是你在循环中调用慢速函数.例如,如果您有一个从数据库查询值并返回它的函数,那么:
while(bContinue && QueryStatusFromDatabase==1){
} //while
会比以下快得多:
while(QueryStatusFromDatabase==1 && bContinue){
} //while
即使它们在逻辑上是相同的.
这是因为第一个可以在一个简单的布尔值为FALSE时立即停止 - 只有在布尔值为TRUE时才运行查询,但第二个将始终运行查询.
除非您需要将所有可能的CPU周期从循环中挤出,否则这些极端情况可能是唯一值得花时间的情况.可以这样想:为了弥补你花时间问这个问题可能需要几十亿次循环.
最糟糕的是当你有一个函数作为一个条件,并且该函数具有代码中某些其他位置秘密期望的副作用.因此,当您进行小优化时,副作用只会在某些时间发生,并且您的代码会以奇怪的方式中断.但这有点像切线.对你的问题的简短回答是"有时,但通常无关紧要."