我可以想到一种情况，后缀比前缀增量慢:

想象一个寄存器a的处理器被用作累加器，它是许多指令中使用的唯一寄存器(一些小型微控制器实际上是这样的)。

现在想象一下下面的程序和它们转换成一个假设的程序集:

前缀增量:

a = ++b + c;

; increment b
LD    A, [&b]
INC   A
ST    A, [&b]

; add with c
ADD   A, [&c]

; store in a
ST    A, [&a]

后缀增加:

a = b++ + c;

; load b
LD    A, [&b]

; add with c
ADD   A, [&c]

; store in a
ST    A, [&a]

; increment b
LD    A, [&b]
INC   A
ST    A, [&b]

注意b的值是如何被强制重新加载的。使用前缀增量，编译器可以只增加值并继续使用它，可能避免重新加载它，因为所需的值在增量之后已经在寄存器中。然而，使用后缀增量，编译器必须处理两个值，一个是旧值，一个是增加的值，正如我上面所示，这会导致更多的内存访问。

当然，如果增量的值没有被使用，比如单个i++;语句，编译器可以(并且确实)简单地生成一个增量指令，而不管后缀或前缀的使用。

As a side note, I'd like to mention that an expression in which there is a b++ cannot simply be converted to one with ++b without any additional effort (for example by adding a - 1). So comparing the two if they are part of some expression is not really valid. Often, where you use b++ inside an expression you cannot use ++b, so even if ++b were potentially more efficient, it would simply be wrong. Exception is of course if the expression is begging for it (for example a = b++ + 1; which can be changed to a = ++b;).

摘自Andrew Koenig的《效率与意图》:

首先，++i是否比i++更有效还不明显，至少在涉及整型变量时是这样。

和:

所以人们应该问的问题不是这两种操作中哪一种更快，而是这两种操作中哪一种更准确地表达了你想要完成的事情。我认为，如果你不使用表达式的值，永远没有理由使用i++而不是++ I，因为永远没有理由复制一个变量的值，增加变量，然后扔掉拷贝。

因此，如果没有使用结果值，则使用++ I。但不是因为它更有效，而是因为它正确地表达了我的意图。

首先:在C中i++和++i之间的差异是可以忽略的。

到细节。

1. 众所周知的c++问题:++i更快

在c++中，如果i是具有重载自增操作符的某种对象，则++i的效率更高。

为什么? 在++i中，对象首先递增，然后可以作为const引用传递给任何其他函数。如果表达式是foo(i++)，这是不可能的，因为现在增量需要在foo()调用之前完成，但旧的值需要传递给foo()。因此，编译器被迫在对原始i执行自增操作符之前复制i。额外的构造函数/析构函数调用是不好的部分。

如上所述，这不适用于基本类型。

2. 鲜为人知的事实是:i++可能更快

如果不需要调用构造函数/析构函数，这在C中总是如此，那么++i和i++应该同样快，对吗?不。他们的速度几乎一样快，但可能有一些小的差异，这是大多数其他答案的错误理解。

How can i++ be faster? The point is data dependencies. If the value needs to be loaded from memory, two subsequent operations need to be done with it, incrementing it, and using it. With ++i, the incrementation needs to be done before the value can be used. With i++, the use does not depend on the increment, and the CPU may perform the use operation in parallel to the increment operation. The difference is at most one CPU cycle, so it is really neglegible, but it is there. And it is the other way round then many would expect.

我的C有点生疏了，所以我提前道歉。就速度而言，我可以理解结果。但是，我对这两个文件是如何得到相同的MD5哈希感到困惑。也许for循环也可以运行，但是下面两行代码不会生成不同的程序集吗?

myArray[i++] = "hello";

vs

myArray[++i] = "hello";

第一个函数将值写入数组，然后将i加1，第二个函数将i加1，然后将值写入数组。我不是汇编专家，但我只是不明白这两行不同的代码如何生成相同的可执行文件。

这只是我的个人意见。

更好的答案是++i有时会更快，但绝不会变慢。

每个人似乎都认为i是一个常规的内置类型，比如int。在这种情况下，将没有可测量的差异。

然而，如果i是复型，那么你很可能会发现一个可测量的差异。对于i++，您必须在递增类之前复制它。根据复制中涉及的内容，它确实可能会变慢，因为使用++i可以只返回最终值。

Foo Foo::operator++()
{
  Foo oldFoo = *this; // copy existing value - could be slow
  // yadda yadda, do increment
  return oldFoo;
}

另一个区别是，使用++i，您可以选择返回一个引用而不是一个值。同样，根据复制对象所涉及的内容，这可能会更慢。

在现实世界中，迭代器的使用就是可能发生这种情况的一个例子。复制迭代器不太可能成为应用程序中的瓶颈，但养成使用++i而不是i++的习惯仍然是一个很好的实践，因为i++的结果不会受到影响。

我总是喜欢预增量，然而……

我想指出的是，即使在调用运算符++函数的情况下，如果函数得到内联，编译器将能够优化掉临时函数。由于操作符++通常很短，并且经常在头文件中实现，因此它很可能被内联。

因此，出于实际目的，这两种形式的性能之间可能没有太大差异。然而，我总是喜欢预增量，因为它似乎更好地直接表达我想说的，而不是依赖于优化器来解决它。

此外，给优化器更少的任务可能意味着编译器运行得更快。