以下两种情况之间是否有任何性能差异:
的第一
int test_some_condition(void);
if( some_variable == 2 && test_some_condition())
{
//body
}
第二名:
int test_some_condition(void);
if( some_variable == 2 )
{
if(test_some_condition())
{
//body
}
}
更新:我知道如何创建测试并测量每个案例的性能或查看为每个案例生成的程序集但我相信我不是第一个遇到这个问题的人,如果遇到这个问题会很好已经测试过的人可以是一个简单的是/否答案。
答案 0 :(得分:4)
在什么方面存在差异?
可读性?是的,有区别。第一个更清晰,更好地表达了你的意图。它在编辑器中占用的行数也较少,这本身并不一定具有优势,但它确实使代码更容易阅读,并且对于任何落后并希望编辑它的人一目了然。
性能/ “速度”?不,我愿意打赌实际的钱,一旦你通过打开优化的编译器运行这两段代码,就没有明显的差别。即使优化已禁用,也不会说服我投注同样的情况也不会花费太多。
为什么呢?因为在C(以及我所知道的所有C派生语言)中,&&
运算符执行短路评估,这意味着如果第一个条件的计算结果为false,那么它甚至都不愿意评估第二个条件,因为整个陈述都无法证明是真的。
当if
运算符未执行短路评估时,嵌套And
语句是VB 6过去的一个常见“优化”技巧。我无法想象在C代码中使用它,除非它增强了可读性。老实说,如果你遇到编译器,没有渲染这两个代码片段在性能方面完全相同,那么是时候抛弃该编译器并停止使用它。这是太阳下最基本的优化,对于编译器编写者来说是一个“低悬的果实”。如果他们无法做到这一点,我会不相信他们的其余代码。
但是,总的来说,担心这类事情(绝对属于“微优化”类别)并不能帮助你编写更好的代码或成为更好的程序员。这只会让你浪费大量时间在Stack Overflow上提问,并为像我这样的用户的声誉做出贡献,这些用户每周都会向2-3个类似问题发布相同的答案。那时候你不花费在编写代码上并以切实的方式提高你的技能。
答案 1 :(得分:2)
任何人都能用现代编译器真正告诉的唯一方法就是查看机器代码。
答案 2 :(得分:2)
应该没有区别。 如果存在差异,则可能无法衡量(即使您做了数百万次,也无法获得确定的结果)。
答案 3 :(得分:1)
在运行10.000.000次的循环中测试这两个示例得出:
$ time ./test1
real 0m0.045s
user 0m0.044s
sys 0m0.001s
$ time ./test2
real 0m0.045s
user 0m0.043s
sys 0m0.003s
另外,请记住,如果表达式的第一部分失败,则永远不会计算第二个表达式。在第一个例子中,这可能不太清楚。
此外,在第一个求值表达式返回false的情况下:
$ time ./test1_1
real 0m0.035s
user 0m0.034s
sys 0m0.001s
$ time ./test2_1
real 0m0.035s
user 0m0.034s
sys 0m0.000s
答案 4 :(得分:0)
如果您正在考虑第一个版本是否始终调用test_some_condition
但第二个版本仅在第一个条件为真时调用它,那么答案是两个版本都是等价的,因为AND运算符是惰性的并且如果第一个参数已经为假,则不会评估其第二个参数。
标准保证了这种行为。这使得合法说:
if (array_size > n && my_array[n] == 1) { ... }
如果没有懒惰保证,这将是破解的代码。
答案 5 :(得分:0)
这两个样本在逻辑上是等价的,前提是复合条件被延迟评估,这意味着在a && b
时,b
在a
已知为假时将不会被评估。因此,即使存在差异,我也不会关心,因为这可能是您正在使用的编译器的伪影(或错误),并且它可能会随着下一个版本或错误修复而改变。