这是一位高级经理在面试时问的问题。
哪个更快?
while(1) {
// Some code
}
or
while(2) {
//Some code
}
我说过两者具有相同的执行速度，因为while中的表达式最终应求值为true或false。在这种情况下，两者都求值为true，并且while条件中没有额外的条件指令。因此，两者将具有相同的执行速度，我更喜欢while(1)。
但面试官自信地说: “检查你的基本知识。While(1)比While(2)快。” (他不是在试探我的信心)
这是真的吗?
请参见:“for(;;)”是否比“while (TRUE)”快?如果不是，人们为什么要使用它?
当前回答
等一下。面试官长得像这个人吗?
面试官自己没能通过面试已经够糟糕的了， 如果这家公司的其他程序员已经“通过”了这个测试呢?
不。求值语句1 == 0和2 == 0应该同样快。我们可以想象，在糟糕的编译器实现中，一个可能比另一个快。但是，没有充分的理由说明其中一个应该比另一个快。
即使在某些模糊的情况下，这种说法是正确的，也不应该基于模糊(在这种情况下，令人毛骨悚然)琐事的知识来评估程序员。不要担心这次面试，最好的办法就是走开。
免责声明:这不是原创呆伯特漫画。这只是一个混搭。
其他回答
当然，我不知道这位经理的真实意图，但我提出了一个完全不同的观点:当一个团队雇佣一个新成员时，了解他如何应对冲突情况是很有用的。
他们让你陷入冲突。如果这是真的，他们很聪明，这个问题也很好。对于某些行业，比如银行业，将你的问题发布到Stack Overflow可能会成为被拒绝的理由。
但我当然不知道，我只是提出一个选择。
因为回答这个问题的人希望得到最快的循环，所以我的回答是，两者都是同样地编译成相同的汇编代码，正如在其他答案中所述。不过，你可以用“循环展开”向面试官建议;一个do {} while循环而不是while循环。
谨慎:您需要确保循环至少总是运行一次。
循环内部应该有一个中断条件。
同样，对于这种循环，我个人更喜欢使用do {} while(42)，因为除了0之外，任何整数都可以完成这项工作。
是的，对于人类来说，while(1)比while(2)快得多!如果我在一个不熟悉的代码库中看到while(1)，我立即知道作者的意图，我的眼球可以继续看下一行。
If I see while(2), I'll probably halt in my tracks and try to figure out why the author didn't write while(1). Did the author's finger slip on the keyboard? Do the maintainers of this codebase use while(n) as an obscure commenting mechanism to make loops look different? Is it a crude workaround for a spurious warning in some broken static analysis tool? Or is this a clue that I'm reading generated code? Is it a bug resulting from an ill-advised find-and-replace-all, or a bad merge, or a cosmic ray? Maybe this line of code is supposed to do something dramatically different. Maybe it was supposed to read while(w) or while(x2). I'd better find the author in the file's history and send them a "WTF" email... and now I've broken my mental context. The while(2) might consume several minutes of my time, when while(1) would have taken a fraction of a second!
我有点夸张，但也只是一点点。代码的可读性非常重要。这一点在面试中很值得一提!
现有的答案显示了由特定编译器为特定目标使用特定选项集生成的代码，并不能完全回答这个问题——除非在特定的上下文中提出了这个问题(例如，“对于带有默认选项的x86_64，使用gcc 4.7.2哪个更快?”)。
就语言定义而言，在抽象机器中while(1)计算整数常数1,while(2)计算整数常数2;在这两种情况下，比较结果是否等于零。语言标准完全没有说明这两种构造的相对性能。
我可以想象，一个极其幼稚的编译器可能会为这两种表单生成不同的机器代码，至少在编译时没有请求优化。
另一方面，C编译器绝对必须在编译时计算一些常量表达式，当它们出现在需要常量表达式的上下文中时。例如，这个:
int n = 4;
switch (n) {
case 2+2: break;
case 4: break;
}
需要诊断;延迟编译器没有将2+2的计算延迟到执行时的选项。由于编译器必须具备在编译时计算常量表达式的能力，因此即使不需要也没有充分的理由不利用这种能力。
C标准(N1570 6.8.5p4)说
一个迭代语句导致一个称为循环体的语句 重复执行，直到控制表达式比较为 0.
所以相关的常数表达式是1 == 0和2 == 0，它们的值都是int值0。(这些比较隐含在while循环的语义中;它们并不作为实际的C表达式存在。)
非常简单的编译器可能会为这两种构造生成不同的代码。例如，对于第一个，它可以生成一个无条件的无限循环(将1视为特殊情况)，对于第二个，它可以生成一个显式的运行时比较，等价于2 != 0。但我从来没有遇到过这样的C编译器，我严重怀疑这样的编译器是否存在。
大多数编译器(我倾向于说所有生产质量的编译器)都有请求额外优化的选项。在这种选择下，任何编译器都不太可能为这两种表单生成不同的代码。
如果编译器为这两种构造生成不同的代码，首先检查不同的代码序列是否具有不同的性能。如果有，请尝试使用优化选项(如果可用)再次编译。如果它们仍然不同，则向编译器供应商提交错误报告。这(不一定)是一个不符合C标准的错误，但几乎可以肯定这是一个应该纠正的问题。
底线:while(1)和while(2)几乎肯定具有相同的性能。它们具有完全相同的语义，任何编译器都没有理由不生成相同的代码。
尽管编译器为while(1)生成比while(2)更快的代码是完全合法的，但在同一个程序中，编译器为while(1)生成比另一个while(1)更快的代码也是合法的。
(你问的问题中还暗含着另一个问题:你如何应对坚持提出一个错误的技术观点的面试官?这可能是一个适合Workplace网站的好问题)。
我能想到为什么while(2)会更慢的唯一原因是:
代码将循环优化为 2 . CMP eax 当减法发生时，你实际上是在减法 A. 00000000 - 00000010 CMP eax, 2 而不是 B. 00000000 - 00000001 CMP eax, 1
CMP只设置标志，不设置结果。所以对于最低有效位，我们知道b是否需要借位，而对于a，你必须做两次减法才能得到借位。
