递增：x++ vs x += 1
我读到，为了清楚起见，许多开发人员使用 x += 1 而不是 x++。我知道 x++ 对于新开发人员来说可能会含糊不清，而 x += 1 总是更清晰，但是两者之间的效率有什么区别吗？
使用 for 循环的示例：
for(x = 0; x < 1000; x += 1) 与 for(x = 0; x <1000; x++)
I了解这通常没什么大不了的，但如果我重复调用执行这种循环的函数，从长远来看它可能会增加。
另一个例子：
while(x < 1000) {
someArray[x];
x += 1;
}
vs
while(x < 1000) {
someArray[x++];
}
能否将 x++ 替换为 x += 1 而不会造成任何性能损失？ 我特别关心第二个示例，因为我使用的是两行而不是一行。
增加数组中的一项怎么样？在大循环中执行时，someArray[i]++ 会比执行 someArray[i] += 1 更快吗？
I've read that many developers use x += 1 instead of x++ for clarity. I understand that x++ can be ambiguous for new developers and that x += 1 is always more clear, but is there any difference in efficiency between the two?
Example using for loop:
for(x = 0; x < 1000; x += 1) vs for(x = 0; x < 1000; x++)
I understand that it's usually not that big of a deal, but if I'm repeatedly calling a function that does this sort of loop, it could add up in the long run.
Another example:
while(x < 1000) {
someArray[x];
x += 1;
}
vs
while(x < 1000) {
someArray[x++];
}
Can x++ be replaced with x += 1 without any performance loss? I'm especially concerned about the second example, because I'm using two lines instead of one.
What about incrementing an item in an array? Will someArray[i]++ be faster than doing someArray[i] += 1 when done in a large loop?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
任何理智或疯狂的编译器都会为两者生成相同的机器代码。
Any sane or insane compiler will produce identical machine code for both.
假设您谈论将这些应用到基类型并且没有自己的类，它们可以产生巨大的差异，它们可以产生相同的输出，特别是当优化打开时。令我惊讶的是，我经常在反编译的应用程序中发现 x += 1 在汇编程序级别上使用 x++（add 与 inc）。
Assuming you talk about applying these to base types and no own classes where they could make a huge difference they can produce the same output especially when optimization is turned on. To my surprise I often found in decompiled applications that x += 1 is used over x++ on assembler level(add vs inc).
任何像样的编译器都应该能够识别两者是相同的，因此最终它们之间不应该有性能差异。
如果你想说服自己就做一个基准测试..
Any decent compiler should be able to recognize that the two are the same so in the end there should be no performance difference between them.
If you want to convince yourself just do a benchmark..
当你说“从长远来看它会增加”时——不要这样想。
相反，用百分比来思考。当您发现程序计数器有 10% 或更多的时间处于该精确代码时，请担心它。
原因是，如果百分比很小，那么通过改进它可以节省的最多费用也很小。
如果时间百分比小于 10%，则几乎可以肯定您在代码的其他部分有更大的加速机会，几乎总是以您可以避免的函数调用的形式。
这是一个示例。
When you say "it could add up in the long run" - don't think about it that way.
Rather, think in terms of percentages. When you find the program counter is in that exact code 10% or more of the time, then worry about it.
The reason is, if the percent is small, then the most you could conceivably save by improving it is also small.
If the percent of time is less than 10%, you almost certainly have much bigger opportunities for speedup in other parts of the code, almost always in the form of function calls you could avoid.
Here's an example.
假设您是一个懒惰的编译器实现者，并且不会费心在机器代码生成模块中编写优化例程。
x = x + 1;
将被翻译为以下代码：
x++ 将被翻译为：
如果在 1 个机器周期内执行一条指令，则 x = x + 1 将需要 3 个机器周期，而 x++ 将需要 1 个机器周期。 （此处使用假设的机器）。
但幸运的是，大多数编译器实现者并不懒惰，并且会在机器代码生成模块中编写优化。所以 x = x+1 和 x++ 应该花费相同的时间来执行。 :-P
Consider you're a lazy compiler implementer and wouldn't bother writing OPTIMIZATION routines in the machine-code-gen module.
x = x + 1;
would get translated to THIS code:
And x++ would get translated to:
if ONE instruction is executed in 1 machine cycle, then x = x + 1 would take 3 machine cycles where as x++ would take 1 machine cycle. (Hypothetical machine used here).
BUT luckily, most compiler implementers are NOT lazy and will write optimizations in the machine-code-gen module. So x = x+1 and x++ SHOULD take equal time to execute. :-P