<p>We have the question <a href="/q/24886">is there a performance difference between <code>i++</code> and <code>++i</code> <strong>in C</strong>?</a></p>

<p>What's the answer for C++?</p>

[{'answer_id': 24904, 'author': 'Mark Harrison', 'author_id': 116, 'author_profile': 'https://Stackoverflow.com/users/116', 'pm_score': 10, 'selected': True, 'text': '<p>[Executive Summary: Use <code>++i</code> if you don\'t have a specific reason to use <code>i++</code>.]</p>\n\n<p>For C++, the answer is a bit more complicated.</p>\n\n<p>If <code>i</code> is a simple type (not an instance of a C++ class), <a href="https://stackoverflow.com/a/24887/194894">then the answer given for C ("No there is no performance difference")</a> holds, since the compiler is generating the code.</p>\n\n<p>However, if <code>i</code> is an instance of a C++ class, then <code>i++</code> and <code>++i</code> are making calls to one of the <code>operator++</code> functions. Here\'s a standard pair of these functions:</p>\n\n<pre><code>Foo&amp; Foo::operator++()   // called for ++i\n{\n    this-&gt;data += 1;\n    return *this;\n}\n\nFoo Foo::operator++(int ignored_dummy_value)   // called for i++\n{\n    Foo tmp(*this);   // variable "tmp" cannot be optimized away by the compiler\n    ++(*this);\n    return tmp;\n}\n</code></pre>\n\n<p>Since the compiler isn\'t generating code, but just calling an <code>operator++</code> function, there is no way to optimize away the <code>tmp</code> variable and its associated copy constructor. If the copy constructor is expensive, then this can have a significant performance impact.</p>\n'}, {'answer_id': 24910, 'author': 'wilhelmtell', 'author_id': 456, 'author_profile': 'https://Stackoverflow.com/users/456', 'pm_score': 6, 'selected': False, 'text': "<p>Yes.  There is.</p>\n\n<p>The ++ operator may or may not be defined as a function.  For primitive types (int, double, ...) the operators are built in, so the compiler will probably be able to optimize your code.  But in the case of an object that defines the ++ operator things are different.</p>\n\n<p>The operator++(int) function must create a copy.  That is because postfix ++ is expected to return a different value than what it holds:  it must hold its value in a temp variable, increment its value and return the temp.  In the case of operator++(), prefix ++, there is no need to create a copy:  the object can increment itself and then simply return itself.</p>\n\n<p>Here is an illustration of the point:</p>\n\n<pre><code>struct C\n{\n    C&amp; operator++();      // prefix\n    C  operator++(int);   // postfix\n\nprivate:\n\n    int i_;\n};\n\nC&amp; C::operator++()\n{\n    ++i_;\n    return *this;   // self, no copy created\n}\n\nC C::operator++(int ignored_dummy_value)\n{\n    C t(*this);\n    ++(*this);\n    return t;   // return a copy\n}\n</code></pre>\n\n<p>Every time you call operator++(int) you must create a copy, and the compiler can't do anything about it.  When given the choice, use operator++();  this way you don't save a copy.  It might be significant in the case of many increments (large loop?) and/or large objects.</p>\n"}, {'answer_id': 25092, 'author': 'James Sutherland', 'author_id': 1739, 'author_profile': 'https://Stackoverflow.com/users/1739', 'pm_score': 5, 'selected': False, 'text': '<p>It\'s not entirely correct to say that the compiler can\'t optimize away the temporary variable copy in the postfix case. A quick test with VC shows that it, at least, can do that in certain cases.</p>\n\n<p>In the following example, the code generated is identical for prefix and postfix, for instance:</p>\n\n<pre><code>#include &lt;stdio.h&gt;\n\nclass Foo\n{\npublic:\n\n    Foo() { myData=0; }\n    Foo(const Foo &amp;rhs) { myData=rhs.myData; }\n\n    const Foo&amp; operator++()\n    {\n        this-&gt;myData++;\n        return *this;\n    }\n\n    const Foo operator++(int)\n    {\n        Foo tmp(*this);\n        this-&gt;myData++;\n        return tmp;\n    }\n\n    int GetData() { return myData; }\n\nprivate:\n\n    int myData;\n};\n\nint main(int argc, char* argv[])\n{\n    Foo testFoo;\n\n    int count;\n    printf("Enter loop count: ");\n    scanf("%d", &amp;count);\n\n    for(int i=0; i&lt;count; i++)\n    {\n        testFoo++;\n    }\n\n    printf("Value: %d\\n", testFoo.GetData());\n}\n</code></pre>\n\n<p>Whether you do ++testFoo or testFoo++, you\'ll still get the same resulting code. In fact, without reading the count in from the user, the optimizer got the whole thing down to a constant. So this:</p>\n\n<pre><code>for(int i=0; i&lt;10; i++)\n{\n    testFoo++;\n}\n\nprintf("Value: %d\\n", testFoo.GetData());\n</code></pre>\n\n<p>Resulted in the following:</p>\n\n<pre><code>00401000  push        0Ah  \n00401002  push        offset string "Value: %d\\n" (402104h) \n00401007  call        dword ptr [__imp__printf (4020A0h)] \n</code></pre>\n\n<p>So while it\'s certainly the case that the postfix version could be slower, it may well be that the optimizer will be good enough to get rid of the temporary copy if you\'re not using it.</p>\n'}, {'answer_id': 25669, 'author': 'Josh', 'author_id': 257, 'author_profile': 'https://Stackoverflow.com/users/257', 'pm_score': 0, 'selected': False, 'text': "<p>An the reason why you ought to use ++i even on built-in types where there's no performance advantage is to create a good habit for yourself.</p>\n"}, {'answer_id': 30745, 'author': 'Mat Noguchi', 'author_id': 1799, 'author_profile': 'https://Stackoverflow.com/users/1799', 'pm_score': 1, 'selected': False, 'text': '<p>@wilhelmtell</p>\n\n<p>The compiler can elide the temporary. Verbatim from the other thread:</p>\n\n<p>The C++ compiler is allowed to eliminate stack based temporaries even if doing so changes program behavior. MSDN link for VC 8: </p>\n\n<p><a href="http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx</a></p>\n'}, {'answer_id': 35085, 'author': 'martjno', 'author_id': 3373, 'author_profile': 'https://Stackoverflow.com/users/3373', 'pm_score': 5, 'selected': False, 'text': '<p>The <a href="https://google.github.io/styleguide/cppguide.html#Preincrement_and_Predecrement" rel="noreferrer">Google C++ Style Guide</a> says:</p>\n<blockquote>\n<p><strong>Preincrement and Predecrement</strong></p>\n<p>Use prefix form (++i) of the increment and decrement operators with\niterators and other template objects.</p>\n<p><strong>Definition:</strong> When a variable is incremented (++i or i++) or decremented (--i or\ni--) and the value of the expression is not used, one must decide\nwhether to preincrement (decrement) or postincrement (decrement).</p>\n<p><strong>Pros:</strong> When the return value is ignored, the &quot;pre&quot; form (++i) is never less\nefficient than the &quot;post&quot; form (i++), and is often more efficient.\nThis is because post-increment (or decrement) requires a copy of i to\nbe made, which is the value of the expression. If i is an iterator or\nother non-scalar type, copying i could be expensive. Since the two\ntypes of increment behave the same when the value is ignored, why not\njust always pre-increment?</p>\n<p><strong>Cons:</strong> The tradition developed, in C, of using post-increment when the\nexpression value is not used, especially in for loops. Some find\npost-increment easier to read, since the &quot;subject&quot; (i) precedes the\n&quot;verb&quot; (++), just like in English.</p>\n<p><strong>Decision:</strong> For simple scalar (non-object) values there is no reason to prefer one\nform and we allow either. For iterators and other template types, use\npre-increment.</p>\n</blockquote>\n'}, {'answer_id': 41154, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 3, 'selected': False, 'text': '<p>I would like to point out an excellent post by Andrew Koenig on Code Talk very recently.</p>\n\n<p><a href="http://dobbscodetalk.com/index.php?option=com_myblog&amp;show=Efficiency-versus-intent.html&amp;Itemid=29" rel="noreferrer">http://dobbscodetalk.com/index.php?option=com_myblog&amp;show=Efficiency-versus-intent.html&amp;Itemid=29</a></p>\n\n<p>At our company also we use convention of ++iter for consistency and performance where applicable. But Andrew raises over-looked detail regarding intent vs performance. There are times when we want to use iter++ instead of ++iter.</p>\n\n<p>So, first decide your intent and if pre or post does not matter then go with pre as it will have some performance benefit by avoiding creation of extra object and throwing it.</p>\n'}, {'answer_id': 42276, 'author': 'Motti', 'author_id': 3848, 'author_profile': 'https://Stackoverflow.com/users/3848', 'pm_score': 3, 'selected': False, 'text': '<p>@Ketan </p>\n\n<blockquote>\n  <p>...raises over-looked detail regarding intent vs performance. There are times when we want to use iter++ instead of ++iter.</p>\n</blockquote>\n\n<p>Obviously post and pre-increment have different semantics and I\'m sure everyone agrees that when the result is used you should use the appropriate operator. I think the question is what should one do when the result is discarded (as in <code>for</code> loops). The answer to <em>this</em> question (IMHO) is that, since the performance considerations are negligible at best, you should do what is more natural. For myself <code>++i</code> is more natural but my experience tells me that I\'m in a minority and using <code>i++</code> will cause less metal overhead for <em>most</em> people reading your code. </p>\n\n<p>After all that\'s the reason the language is not called "<em><code>++C</code></em>".[*]</p>\n\n<p>[*] Insert obligatory discussion about <code>++C</code> being a more logical name. </p>\n'}, {'answer_id': 71340, 'author': '0124816', 'author_id': 11521, 'author_profile': 'https://Stackoverflow.com/users/11521', 'pm_score': 2, 'selected': False, 'text': "<p>Mark: Just wanted to point out that operator++'s are good candidates to be inlined, and if the compiler elects to do so, the redundant copy will be eliminated in most cases. (e.g. POD types, which iterators usually are.)</p>\n\n<p>That said, it's still better style to use ++iter in most cases. :-)</p>\n"}, {'answer_id': 445270, 'author': 'Blaisorblade', 'author_id': 53974, 'author_profile': 'https://Stackoverflow.com/users/53974', 'pm_score': 0, 'selected': False, 'text': '<p>The intended question was about when the result is unused (that\'s clear from the question for C). Can somebody fix this since the question is "community wiki"?</p>\n\n<p>About premature optimizations, Knuth is often quoted. That\'s right. but Donald Knuth would never defend with that the horrible code which you can see in these days. Ever seen a = b + c among Java Integers (not int)? That amounts to 3 boxing/unboxing conversions. Avoiding stuff like that is important. And uselessly writing i++ instead of ++i is the same mistake.\nEDIT: As phresnel nicely puts it in a comment, this can be summed up as "premature optimization is evil, as is premature pessimization".</p>\n\n<p>Even the fact that people are more used to i++ is an unfortunate C legacy, caused by a conceptual mistake by K&amp;R (if you follow the intent argument, that\'s a logical conclusion; and defending K&amp;R because they\'re K&amp;R is meaningless, they\'re great, but they aren\'t great as language designers; countless mistakes in the C design exist, ranging from gets() to strcpy(), to the strncpy() API (it should have had the strlcpy() API since day 1)).</p>\n\n<p>Btw, I\'m one of those not used enough to C++ to find ++i annoying to read. Still, I use that since I acknowledge that it\'s right.</p>\n'}, {'answer_id': 1319291, 'author': 'Mike Dunlavey', 'author_id': 23771, 'author_profile': 'https://Stackoverflow.com/users/23771', 'pm_score': 2, 'selected': False, 'text': '<p>@Mark: I deleted my previous answer because it was a bit flip, and deserved a downvote for that alone. I actually think it\'s a good question in the sense that it asks what\'s on the minds of a lot of people.</p>\n\n<p>The usual answer is that ++i is faster than i++, and no doubt it is, but the bigger question is "when should you care?"</p>\n\n<p>If the fraction of CPU time spent in incrementing iterators is less than 10%, then you may not care.</p>\n\n<p>If the fraction of CPU time spent in incrementing iterators is greater than 10%, you can look at which statements are doing that iterating. See if you could just increment integers rather than using iterators. Chances are you could, and while it may be in some sense less desirable, chances are pretty good you will save essentially all the time spent in those iterators.</p>\n\n<p>I\'ve seen an example where the iterator-incrementing was consuming well over 90% of the time. In that case, going to integer-incrementing reduced execution time by essentially that amount. (i.e. better than 10x speedup)</p>\n'}, {'answer_id': 5616980, 'author': 'Geoffroy', 'author_id': 610351, 'author_profile': 'https://Stackoverflow.com/users/610351', 'pm_score': 0, 'selected': False, 'text': "<p>Both are as fast ;)\nIf you want it is the same calculation for the processor, it's just the order in which it is done that differ.</p>\n\n<p>For example, the following code :</p>\n\n<pre><code>#include &lt;stdio.h&gt;\n\nint main()\n{\n    int a = 0;\n    a++;\n    int b = 0;\n    ++b;\n    return 0;\n}\n</code></pre>\n\n<p>Produce the following assembly :</p>\n\n<blockquote>\n<pre><code> 0x0000000100000f24 &lt;main+0&gt;: push   %rbp\n 0x0000000100000f25 &lt;main+1&gt;: mov    %rsp,%rbp\n 0x0000000100000f28 &lt;main+4&gt;: movl   $0x0,-0x4(%rbp)\n 0x0000000100000f2f &lt;main+11&gt;:    incl   -0x4(%rbp)\n 0x0000000100000f32 &lt;main+14&gt;:    movl   $0x0,-0x8(%rbp)\n 0x0000000100000f39 &lt;main+21&gt;:    incl   -0x8(%rbp)\n 0x0000000100000f3c &lt;main+24&gt;:    mov    $0x0,%eax\n 0x0000000100000f41 &lt;main+29&gt;:    leaveq \n 0x0000000100000f42 &lt;main+30&gt;:    retq\n</code></pre>\n</blockquote>\n\n<p>You see that for a++ and b++ it's an incl mnemonic, so it's the same operation ;)</p>\n"}, {'answer_id': 9519095, 'author': 'Sebastian Mach', 'author_id': 76722, 'author_profile': 'https://Stackoverflow.com/users/76722', 'pm_score': 6, 'selected': False, 'text': '<p>Here\'s a benchmark for the case when increment operators are in different translation units. Compiler with g++ 4.5.</p>\n\n<p>Ignore the style issues for now</p>\n\n<pre><code>// a.cc\n#include &lt;ctime&gt;\n#include &lt;array&gt;\nclass Something {\npublic:\n    Something&amp; operator++();\n    Something operator++(int);\nprivate:\n    std::array&lt;int,PACKET_SIZE&gt; data;\n};\n\nint main () {\n    Something s;\n\n    for (int i=0; i&lt;1024*1024*30; ++i) ++s; // warm up\n    std::clock_t a = clock();\n    for (int i=0; i&lt;1024*1024*30; ++i) ++s;\n    a = clock() - a;\n\n    for (int i=0; i&lt;1024*1024*30; ++i) s++; // warm up\n    std::clock_t b = clock();\n    for (int i=0; i&lt;1024*1024*30; ++i) s++;\n    b = clock() - b;\n\n    std::cout &lt;&lt; "a=" &lt;&lt; (a/double(CLOCKS_PER_SEC))\n              &lt;&lt; ", b=" &lt;&lt; (b/double(CLOCKS_PER_SEC)) &lt;&lt; \'\\n\';\n    return 0;\n}\n</code></pre>\n\n<hr>\n\n<h1>O(n) increment</h1>\n\n<h2>Test</h2>\n\n<pre><code>// b.cc\n#include &lt;array&gt;\nclass Something {\npublic:\n    Something&amp; operator++();\n    Something operator++(int);\nprivate:\n    std::array&lt;int,PACKET_SIZE&gt; data;\n};\n\n\nSomething&amp; Something::operator++()\n{\n    for (auto it=data.begin(), end=data.end(); it!=end; ++it)\n        ++*it;\n    return *this;\n}\n\nSomething Something::operator++(int)\n{\n    Something ret = *this;\n    ++*this;\n    return ret;\n}\n</code></pre>\n\n<h2>Results</h2>\n\n<p>Results (timings are in seconds) with g++ 4.5 on a virtual machine:</p>\n\n<pre><code>Flags (--std=c++0x)       ++i   i++\n-DPACKET_SIZE=50 -O1      1.70  2.39\n-DPACKET_SIZE=50 -O3      0.59  1.00\n-DPACKET_SIZE=500 -O1    10.51 13.28\n-DPACKET_SIZE=500 -O3     4.28  6.82\n</code></pre>\n\n<hr>\n\n<h1>O(1) increment</h1>\n\n<h2>Test</h2>\n\n<p>Let us now take the following file:</p>\n\n<pre><code>// c.cc\n#include &lt;array&gt;\nclass Something {\npublic:\n    Something&amp; operator++();\n    Something operator++(int);\nprivate:\n    std::array&lt;int,PACKET_SIZE&gt; data;\n};\n\n\nSomething&amp; Something::operator++()\n{\n    return *this;\n}\n\nSomething Something::operator++(int)\n{\n    Something ret = *this;\n    ++*this;\n    return ret;\n}\n</code></pre>\n\n<p>It does nothing in the incrementation. This simulates the case when incrementation has constant complexity.</p>\n\n<h2>Results</h2>\n\n<p>Results now vary extremely:</p>\n\n<pre><code>Flags (--std=c++0x)       ++i   i++\n-DPACKET_SIZE=50 -O1      0.05   0.74\n-DPACKET_SIZE=50 -O3      0.08   0.97\n-DPACKET_SIZE=500 -O1     0.05   2.79\n-DPACKET_SIZE=500 -O3     0.08   2.18\n-DPACKET_SIZE=5000 -O3    0.07  21.90\n</code></pre>\n\n<hr>\n\n<h1>Conclusion</h1>\n\n<h2>Performance-wise</h2>\n\n<p>If you do not need the previous value, make it a habit to use pre-increment. Be consistent even with builtin types, you\'ll get used to it and do not run risk of suffering unecessary performance loss if you ever replace a builtin type with a custom type.</p>\n\n<h2>Semantic-wise</h2>\n\n<ul>\n<li><code>i++</code> says <code>increment i, I am interested in the previous value, though</code>.</li>\n<li><code>++i</code> says <code>increment i, I am interested in the current value</code> or <code>increment i, no interest in the previous value</code>. Again, you\'ll get used to it, even if you are not right now.</li>\n</ul>\n\n<h2>Knuth.</h2>\n\n<p>Premature optimization is the root of all evil. As is premature pessimization.</p>\n'}, {'answer_id': 13256938, 'author': 'bwDraco', 'author_id': 681231, 'author_profile': 'https://Stackoverflow.com/users/681231', 'pm_score': 2, 'selected': False, 'text': "<p>The performance difference between <code>++i</code> and <code>i++</code> will be more apparent when you think of operators as value-returning functions and how they are implemented.  To make it easier to understand what's happening, the following code examples will use <code>int</code> as if it were a <code>struct</code>.</p>\n\n<p><code>++i</code> increments the variable, <em>then</em> returns the result.  This can be done in-place and with minimal CPU time, requiring only one line of code in many cases:</p>\n\n<pre><code>int&amp; int::operator++() { \n     return *this += 1;\n}\n</code></pre>\n\n<p>But the same cannot be said of <code>i++</code>.</p>\n\n<p>Post-incrementing, <code>i++</code>, is often seen as returning the original value <em>before</em> incrementing.  However, <em>a function can only return a result when it is finished</em>.  As a result, it becomes necessary to create a copy of the variable containing the original value, increment the variable, then return the copy holding the original value:</p>\n\n<pre><code>int int::operator++(int&amp; _Val) {\n    int _Original = _Val;\n    _Val += 1;\n    return _Original;\n}\n</code></pre>\n\n<p>When there is no functional difference between pre-increment and post-increment, the compiler can perform optimization such that there is no performance difference between the two.  However, if a composite data type such as a <code>struct</code> or <code>class</code> is involved, the copy constructor will be called on post-increment, and it will not be possible to perform this optimization if a deep copy is needed.  As such, pre-increment generally is faster and requires less memory than post-increment.</p>\n"}, {'answer_id': 22266658, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': -1, 'selected': False, 'text': '<p><code>++i</code> is faster than <code>i++</code> because it doesn\'t return an old copy of the value.</p>\n\n<p>It\'s also more intuitive:</p>\n\n<pre><code>x = i++;  // x contains the old value of i\ny = ++i;  // y contains the new value of i \n</code></pre>\n\n<p><a href="http://ideone.com/ivrj9b" rel="nofollow">This C example</a> prints "02" instead of the "12" you might expect:</p>\n\n<pre><code>#include &lt;stdio.h&gt;\n\nint main(){\n    int a = 0;\n    printf("%d", a++);\n    printf("%d", ++a);\n    return 0;\n}\n</code></pre>\n\n<p><a href="http://ideone.com/OMovKe" rel="nofollow">Same for C++</a>:</p>\n\n<pre><code>#include &lt;iostream&gt;\nusing namespace std;\n\nint main(){\n    int a = 0;\n    cout &lt;&lt; a++;\n    cout &lt;&lt; ++a;\n    return 0;\n}\n</code></pre>\n'}, {'answer_id': 43215369, 'author': 'Hans Malherbe', 'author_id': 126225, 'author_profile': 'https://Stackoverflow.com/users/126225', 'pm_score': 3, 'selected': False, 'text': "<ol>\n<li><strong>++i</strong> - faster <strong>not using</strong> the return value</li>\n<li><strong>i++</strong> - faster <strong>using</strong> the return value</li>\n</ol>\n\n<p>When <strong>not using</strong> the return value the compiler is guaranteed not to use a temporary in the case of <strong>++i</strong>. Not guaranteed to be faster, but guaranteed not to be slower.</p>\n\n<p>When <strong>using</strong> the return value <strong>i++</strong> allows the processor to push both the\n increment and the left side into the pipeline since they don't depend on each other. ++i may stall the pipeline because the processor cannot start the left side until the pre-increment operation has meandered all the way through. Again, a pipeline stall is not guaranteed, since the processor may find other useful things to stick in.</p>\n"}, {'answer_id': 49564789, 'author': 'Severin Pappadeux', 'author_id': 4044696, 'author_profile': 'https://Stackoverflow.com/users/4044696', 'pm_score': -1, 'selected': False, 'text': "<p>Time to provide folks with gems of wisdom  ;) - there is simple trick to make C++ postfix increment behave pretty much the same as prefix increment (Invented this for myself, but the saw it as well in other people code, so I'm not alone).</p>\n\n<p>Basically, trick is to use helper class to postpone increment after the return, and RAII comes to rescue</p>\n\n<pre><code>#include &lt;iostream&gt;\n\nclass Data {\n    private: class DataIncrementer {\n        private: Data&amp; _dref;\n\n        public: DataIncrementer(Data&amp; d) : _dref(d) {}\n\n        public: ~DataIncrementer() {\n            ++_dref;\n        }\n    };\n\n    private: int _data;\n\n    public: Data() : _data{0} {}\n\n    public: Data(int d) : _data{d} {}\n\n    public: Data(const Data&amp; d) : _data{ d._data } {}\n\n    public: Data&amp; operator=(const Data&amp; d) {\n        _data = d._data;\n        return *this;\n    }\n\n    public: ~Data() {}\n\n    public: Data&amp; operator++() { // prefix\n        ++_data;\n        return *this;\n    }\n\n    public: Data operator++(int) { // postfix\n        DataIncrementer t(*this);\n        return *this;\n    }\n\n    public: operator int() {\n        return _data;\n    }\n};\n\nint\nmain() {\n    Data d(1);\n\n    std::cout &lt;&lt;   d &lt;&lt; '\\n';\n    std::cout &lt;&lt; ++d &lt;&lt; '\\n';\n    std::cout &lt;&lt;   d++ &lt;&lt; '\\n';\n    std::cout &lt;&lt; d &lt;&lt; '\\n';\n\n    return 0;\n}\n</code></pre>\n\n<p>Invented is for some heavy custom iterators code, and it cuts down run-time. Cost of prefix vs postfix is one reference now, and if this is custom operator doing heavy moving around, prefix and postfix yielded the same run-time for me.</p>\n"}, {'answer_id': 65016498, 'author': 'Siddhant Jain', 'author_id': 13828587, 'author_profile': 'https://Stackoverflow.com/users/13828587', 'pm_score': -1, 'selected': False, 'text': '<p><code>++i</code> is faster than <code>i = i +1</code> because in <code>i = i + 1</code> two operation are taking place, first increment and second assigning it to a variable. But in <code>i++</code> only increment operation is taking place.</p>\n'}, {'answer_id': 71049628, 'author': 'Tristan', 'author_id': 668455, 'author_profile': 'https://Stackoverflow.com/users/668455', 'pm_score': 0, 'selected': False, 'text': '<p>Since you asked for C++ too, here is a benchmark for java (made with jmh) :</p>\n<pre><code>private static final int LIMIT = 100000;\n\n@Benchmark\npublic void postIncrement() {\n    long a = 0;\n    long b = 0;\n    for (int i = 0; i &lt; LIMIT; i++) {\n        b = 3;\n        a += i * (b++);\n    }\n    doNothing(a, b);\n}\n\n@Benchmark\npublic void preIncrement() {\n    long a = 0;\n    long b = 0;\n    for (int i = 0; i &lt; LIMIT; i++) {\n        b = 3;\n        a += i * (++b);\n    }\n    doNothing(a, b);\n}  \n</code></pre>\n<p>The result shows, even when the value of the incremented variable (b) is actually used in some computation, forcing the need to store an additional value in case of post-increment, the time per operation is exactly the same :</p>\n<pre><code>Benchmark                         Mode  Cnt  Score   Error  Units\nIncrementBenchmark.postIncrement  avgt   10  0,039   0,001  ms/op\nIncrementBenchmark.preIncrement   avgt   10  0,039   0,001  ms/op\n</code></pre>\n'}, {'answer_id': 74031262, 'author': 'glades', 'author_id': 11770390, 'author_profile': 'https://Stackoverflow.com/users/11770390', 'pm_score': 0, 'selected': False, 'text': '<h2>i++ is sometimes faster than ++i!</h2>\n<p>For x86-architectures that use ILP (instruction level paralellism) i++ might in some situations outperform ++i.</p>\n<p>Why? Because of data dependencies. Modern CPUs parallelise a lot of stuff. If the next few CPU cycles don\'t have any direct dependency on the <em><strong>incremented</strong></em> value of i, the CPU might omit microcode to delay the increment of i and shove it in a &quot;free slot&quot;. This means that you essentially get a &quot;free&quot; increment.</p>\n<p>I don\'t know how far ILE goes in this case but I suppose if the iterator becomes too complicated and does pointer dereferencing this might not work.</p>\n<p>Here\'s a talk by Andrei Alexandrescu explaining the concept: <a href="https://www.youtube.com/watch?v=vrfYLlR8X8k&amp;list=WL&amp;index=5" rel="nofollow noreferrer">https://www.youtube.com/watch?v=vrfYLlR8X8k&amp;list=WL&amp;index=5</a></p>\n'}]
['https://Stackoverflow.com/questions/24901', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/116/']