仅当计算路径依赖于数据时：

a={1,1,1,1,1000,1,1,1,1}
while (i<=4)
{
     for(j from 0 to a[i]){ do_work(); }
     i++;
}

将计算250倍以上的时间（i<4）

真实世界的例子是计算曼德布洛特集合。如果包含一个迭代1000000次的像素，它将导致延迟，但与<=使用概率的重合度太低。

您可以说这行在大多数脚本语言中都是正确的，因为额外的字符会导致代码处理稍慢。然而，正如上面的答案所指出的，它在C++中应该没有任何影响，而使用脚本语言所做的任何事情都可能不太关心优化。

也许那本无名书的作者读到a>0比a>=1跑得更快，并认为这是普遍正确的。

但这是因为涉及0（因为CMP可以根据体系结构，例如用OR替换），而不是因为<。

至少，如果这是真的，编译器可以轻松地优化a<=b到！（a>b），因此，即使比较本身实际上较慢，但除了最简单的编译器之外，您也不会注意到差异。

假设我们讨论的是内部整数类型，不可能一个比另一个更快。它们显然在语义上是相同的。它们都要求编译器做完全相同的事情。只有一个严重损坏的编译器才能为其中一个生成劣质代码。

如果在某些平台上，对于简单整数类型，<比<=快，编译器应始终将常量的<=转换为<。任何没有这样做的编译器都将是一个糟糕的编译器（对于该平台）。

对于浮点代码，甚至在现代体系结构上，<=比较可能确实会慢一些（一条指令）。这是第一个函数：

int compare_strict(double a, double b) { return a < b; }

在PowerPC上，首先执行浮点比较（更新条件寄存器cr），然后将条件寄存器移动到GPR，将“比较小于”位移位到位，然后返回。它需要四个指令。

现在考虑一下这个函数：

int compare_loose(double a, double b) { return a <= b; }

这需要与上面的compare_strict相同的工作，但现在有两个有趣的位：“小于”和“等于”。这需要一个额外的指令（cror-condition寄存器逐位OR）将这两个位组合为一。因此，compare_sloose需要五条指令，而compare_sstrict需要四条指令。

您可能认为编译器可以这样优化第二个函数：

int compare_loose(double a, double b) { return ! (a > b); }

然而，这将错误地处理NaN。NaN1<=NaN2和NaN1>NaN2都需要评估为假。