短路是否使程序的执行更快，并且分析在条件语句中放在第一位的语句是否值得？ 例如（如果我们说C++，如果我们做了不同的话） 在&&运算符中，如果我知道一条语句的结果为0的频率更高/可能性更大，那么我应该将另一条语句放在左侧，将另一条语句放在右侧吗

| |运算符也是如此，如果我知道一个语句的结果更频繁/概率更高，那么另一个语句应该放在左边，另一个语句放在右边吗

---

现在这样做会导致大量的时间分析程序，但是如果这确实加快了程序的执行时间，它是值得做的吗？这是嵌入式/实时系统程序员在需要时加速他们的应用程序的事情吗？

你也必须考虑，每一方的评估成本有多高

if (veryCostlyOftenFalse() && veryCheapRareFalse()) // may be faster other way around

除非超过50%的源代码是表达式求值和分支，否则我会说这是最后的优化手段，当您对其他一切都满意时

---

嵌入式/实时应用程序程序员主要关注以下顺序：

当然，在速度和空间之间找到合理的平衡点

内存中的数据结构（当由这些算法执行时，尽可能频繁地命中缓存）

使用真实数据分析真实应用程序，以查看是否存在一些意外瓶颈，并修复这些瓶颈

如果你在某个地方丢失了一两个时钟，并且周围有一些复杂的

if

，那么是的，这可能会有帮助

---

首先，确保你不是过早优化的受害者

话虽如此，请确保尽一切努力加快程序的瓶颈

---

在某些情况下，按照你所说的做短路可能是个好主意，但这在很大程度上取决于你的陈述

例如，如果您有以下内容：

if(slowFunction() && complexConditionRootsAndExponents && ConditionUsuallyZero)

那么你可能会希望最后一个学期是第一个，不是吗

然而，要小心，事情并非总是按照逻辑顺序排列的。例如，在我的回答中，可以看到短路会影响程序的执行流程

---

TL；博士

---

但是，一般来说，通过在条件中排列项来获得显著的加速是很少见的关注计划的瓶颈，并尽可能地解决它

问题的答案是：是的，它确实会影响性能

性能增益是否值得寻找可以改进的位置和更改程序的成本，只有您才能回答

在大多数情况下，性能变化将很小，但如果涉及的某些操作成本很高，则可能会很显著

请注意，也可能存在正确性问题。例如，如果在

if（foo（）| | bar（））

中，如果

foo

返回true，则从不调用

bar

是很重要的，那么重新排序调用将是一个错误

首先确保你的程序是正确的。然后，如果速度太慢；对其进行分析并优化其影响最大的位置。这可能是短路情况下的评估顺序，但在大多数情况下，这将是另一种情况。

视情况而定。 如果语句非常简单：

if(y == 4 || x == 2)

假设x==2的频率要高得多，因此我们可以通过如下方式缩短执行：

if(x == 2 || y == 4)

但是您会看到，我们不会从中获得太多好处，因为这些语句非常简单，在这个级别上优化代码可能没有那么大的价值

现在考虑一个例子，比如：

if(y == an_expensive_function() || x == 2)

这里假设一个昂贵的函数（）是一个非常昂贵的操作，比如说它的复杂度是指数级的，那么把这个语句放在下面肯定是有意义的：

if(x == 2 || y == an_expensive_function())

进行短路

嵌入式和应用程序开发人员或任何开发人员一开始可能不考虑在这样精细的粒度下进行优化，如果这不会给它们带来很多好处的话。如果事情对他们有利的话，他们甚至不会考虑。

---

因此，作为一名开发人员，我们需要检查，在这样的级别上分析和优化代码需要多长时间，我们从中获得了多少好处。

当然。如果您的条件格式为：

if ( x() && y() ) ...

y的计算成本很高，x的计算成本很低，而且经常失败， 这将提高代码的本地性能

所以你想知道：

• 是程序中性能敏感部分的条件（如果不是，优化它没有意义，请写清楚）
• 短路表达式元件计算的相对成本
• 哪些便宜的计算经常失败（对于&&）或成功（对于| |）

---

在这种情况下，重新排列短路表达式元素通常是值得的。

值得吗？这取决于许多因素。最大的问题是进行此调整需要多少成本，以及从增加的性能中节省多少成本。原则上是的，这就是短路运算符存在的原因。首先确保程序正确无误。然后，如果速度太慢，请对其进行配置。解决任何使其减速的问题。在分析之前不要浪费时间。这是我的意见,；投票决定以主要基于意见的方式结束。@OmidCompSCI：通常最快的解决方案通常简单、优雅（在源代码级别），因此这些语句通常以最佳顺序自然结束。否则，您可能正在处理一些必须从探查器获取硬数据的问题。如果不使用当今复杂的机器进行测量，优化是没有捷径的，太多好的意图很容易适得其反。我曾经遇到过这样一个案例：在一个非常便宜的条件之前，先检查几个昂贵的条件，然后再检查一个，这将在90%的时间内拒绝整个过程。R