显而易见的答案是:正如所发布的，两个片段将运行一个同样繁忙的无限循环，这使得程序无限慢。

虽然从技术上讲，将C关键字重新定义为宏将具有未定义的行为，但这是我能想到的使任何一个代码片段快速的唯一方法:你可以在两个片段之上添加这一行:

#define while(x) sleep(x);

它确实会使while(1)比while(2)快一倍(或慢一半)。

如果你担心优化，你应该使用

for (;;)

因为它没有检验。(愤世嫉俗者模式)

现有的答案显示了由特定编译器为特定目标使用特定选项集生成的代码，并不能完全回答这个问题——除非在特定的上下文中提出了这个问题(例如，“对于带有默认选项的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网站的好问题)。

当然，我不知道这位经理的真实意图，但我提出了一个完全不同的观点:当一个团队雇佣一个新成员时，了解他如何应对冲突情况是很有用的。

他们让你陷入冲突。如果这是真的，他们很聪明，这个问题也很好。对于某些行业，比如银行业，将你的问题发布到Stack Overflow可能会成为被拒绝的理由。

但我当然不知道，我只是提出一个选择。

这取决于编译器。

如果它优化了代码，或者对于一个特定的指令集，如果它用相同数量的指令计算1和2为真，那么执行速度将是相同的。

在实际情况下，它总是同样快，但可以想象在特定的编译器和特定的系统中，这将得到不同的计算。

我的意思是:这不是一个与语言(C)相关的问题。

等一下。面试官长得像这个人吗?

面试官自己没能通过面试已经够糟糕的了， 如果这家公司的其他程序员已经“通过”了这个测试呢?

不。求值语句1 == 0和2 == 0应该同样快。我们可以想象，在糟糕的编译器实现中，一个可能比另一个快。但是，没有充分的理由说明其中一个应该比另一个快。

即使在某些模糊的情况下，这种说法是正确的，也不应该基于模糊(在这种情况下，令人毛骨悚然)琐事的知识来评估程序员。不要担心这次面试，最好的办法就是走开。

免责声明:这不是原创呆伯特漫画。这只是一个混搭。