在`while (1)`和`for (;;)`之间有速度差异吗？
在`while (1)`和`for (;;)`之间有速度差异吗？
有同事在看到我在Perl脚本中使用while (1)后，今天断言for (;;)更快。我争辩说它们应该是一样的，希望解释器可以优化出任何差异。我设置了一个脚本，运行了1,000,000,000次循环和同样数量的while循环，并记录它们之间的时间。我找不到明显的差异。我的同事说他的一位教授告诉他while (1)会进行比较1 == 1，而for (;;)则不会。我们用100倍的迭代次数重复了相同的测试，使用C++，差异可以忽略不计。然而，这是一个生动的例子，说明编译代码相对于脚本语言有多快。\n简短版本...\n如果你需要一个无限循环来跳出，有什么理由更喜欢while (1)而不是for (;;)吗？\n注意：如果问题不清楚，请注意这只是一次有趣的学术讨论，朋友之间的交流。我知道这不是所有程序员都应该苦苦思考的重要概念。谢谢所有给出了很好答案的人，我（而且我确定其他人也是）从这次讨论中学到了一些东西。\n更新：上述的同事在下面发表了回应。\n为了防止它被埋没，我引用如下：\n
\n这是来自一位AMD汇编程序员的说法。他说C程序员（人们）没有意识到他们的代码有低效性。他说今天，gcc编译器非常出色，让像他这样的人失去了工作机会。他说例如，告诉我关于
while 1和for(;;)的区别。我现在出于习惯使用它，但是现在的gcc和特别是解释器会对它们进行相同的操作（处理器跳转），因为它们已经被优化了。\n
在使用GCC编译器时，使用-S选项进行汇编，不进行链接，可以发现while循环和for循环编译成的汇编代码是相同的。
因此，从编译器的角度来看，while循环和for循环在速度上没有区别。
然而，从语义的角度来看，while循环和for循环的使用场景有所不同。while循环适用于需要在条件满足的情况下重复执行一段代码的情况，而for循环适用于已知循环次数的情况。
因此，正确选择while循环还是for循环应该根据具体的业务需求和代码逻辑来决定。
总结起来，从编译器的角度来看，while循环和for循环在速度上没有区别。然而，从语义的角度来看，while循环和for循环的使用场景有所不同，应根据具体需求选择合适的循环结构。
在上述内容中，提到了使用while(1)和for(;;)进行无限循环的问题。虽然在可读性上，while(1)和while(true)比for(;;)更易读，但这只是个人喜好的问题。有人提出了使用宏定义来增加可读性，如#define EVER ;; for(EVER)和#define ever (;;) forever;，但也有人担心这样会给维护程序员（通常是自己）带来困惑。
还某些情况下使用while(true)比for(;;)更可读，因此在其他条件相同的情况下，while(true)是更好的代码。还有人表示PC-Lint对while(true)会发出警告，而对for(;;)则不会。
在K&R（第二版）中，建议使用#define forever for (;;)，但仅作为宏替换的示例，并不意味着我们应该始终使用这种形式的无限循环。事实上，这种无限循环的习惯用法（即使在半个世纪前的第一版中也提到过）是for (;;)，这也是为什么for语句允许省略第二个表达式的原因。
对于while (1) vs. for (;;) Is there a speed difference?这个问题，没有明确的答案。选择使用哪种形式的无限循环取决于个人偏好和可读性的权衡。
在Perl中，无限循环的for(;;)和while(1)生成的汇编代码是相同的。同样，在GCC中，无限循环的for(;;)和while(1)生成的汇编代码也是相同的。因此，它们在许多编译器中是相同的。
虽然在一些编译器中可能不是这种情况，但是循环内部的代码执行速度往往比循环本身的速度更快，所以谁会在意循环本身的速度呢？
在Perl中，使用B::Deparse尝试反解析一个无限for循环会返回一个while循环。
对于Perl来说，它们的运行速度是相同的，因为计算机执行的是完全相同的操作。
然而，这个回答在关于Perl的部分是完全错误的。有关详细信息，请参见我的回答。
虽然这个回答在关于运行时开销的部分是部分错误的，但它只关注运行时开销。我无法想象在循环的解析时间成为决定程序运行速度的关键因素的情况下会发生什么样的情况。
尽管如此，个人认为即使循环只被解析一次，我也不想浪费CPU周期。但是我是在Z80平台上学习编程的，它比今天的计算机稍微慢一些。哦，这个问题是认真的吗？我以为整个问题都是开玩笑的...至少我的回答显然是开玩笑的 🙂