1

Is i = i + 1 faster than ++i for C++11? I hear that ++i is faster than i++ for classes, but not for simple types. Is there a similar comparison between i = i + 1 and these other two?
Thanks!

EDIT 1: I use g++, but I'd be happy to know how this works on other compilers as well.
EDIT 2: This question is different from this one because it specifically asks about i = i + 1, as opposed to just talking about the difference between ++i and i++.

EDIT 3: (TonyD - grammatically edited by QuantumFool) The i = i + 1 aspect of the question is a duplicate of this

Community
  • 1
  • 1
QuantumFool
  • 609
  • 3
  • 10
  • 29
  • 2
    I think it depends on the compiler you are using. However, "established wisdom" is in favor of `++i`, because it usually corresponds to one or two machine operations. – Gordon Linoff Jul 03 '15 at 01:26
  • You need to define your types. What you have is ambiguous. That said, for `int`, with sufficient optimization you should get the same performance from `++i`, `i++`, `i = i + 1`, `i += 1` and whatever else you can concoct. In other words, you also have to specify the compiler and flags. Performance is a feature of the tools, not the language. – Adam Jul 03 '15 at 01:33
  • While `i = i + 1` and `++i` in the title is different to `++i` vs `i++` - the latter features prominently in the question proper, and is the only bit of the question where there're "issues" to explain... hence marking as duplicate. – Tony Delroy Jul 03 '15 at 01:55
  • @TonyD This is not a duplicate, its about `i = i + 1` and `i++`. – Galik Jul 03 '15 at 02:25
  • @Galik: partly, and to that extent it's a duplicate of yet other questions - e.g. http://stackoverflow.com/questions/26199576/understanding-more-about-i-and-i-i1 Typically, throwing two questions together that have already been answered independently doesn't make for a good new question.... – Tony Delroy Jul 03 '15 at 03:02

2 Answers2

5

Apart from compiler you are using, it also depends on the optimization setting you used. If you want to know, disassemble it to see the result of compilation for specific compiler + optimization setting.

However at least there are something that are mostly true:

  1. i++ will not be slower than i = i+1
  2. ++i will not be slower than i++ if you are only doing incrementation.
  3. It is always preferred to write ++i if possible even for simple type. Not because of performance, but to build up a good practice so you do not need to double-think when you are doing ++ on an object.
Adrian Shum
  • 38,812
  • 10
  • 83
  • 131
  • `++i will not be slower than i++` this is only true for non-userdefined types - for user-defined types they are two different operators. `operator++()` is prefix and `operator++(int)` is postfix. – kfsone Jul 03 '15 at 01:36
  • 1
    @kfsone that's why I said "***mostly true***". Of course you can write a class that its prefix incrementation is obviously slower than postfix. However, normally for user defined type, postfix and prefix incrementation share similar logic but postfix needs a temp object to hold the value before incrementation, hence *normally* postfix is slower than prefix – Adrian Shum Jul 03 '15 at 01:40
0
  1. if the type is not class , like int and so on, they are almost the same
  2. if the type is class, ++i is faster than i++,because ++i returns lvalue, i++ returns rvalue;

  class A{
        private:
           int i;
        public:
           A( int k =0): i(k){}
           A operator++(){  // i++
              A temp=*this;  // need create a new object
              i++;
              return temp;
        }
           A & operator++(int){ // ++i
               i++;
               return *this;
        }
        };
kiviak
  • 1,083
  • 9
  • 10
  • *"`++I` is faster than `i++`,because `++I` returns lvalue, `i++` returns rvalue"* - this is not true; for most classes there will be no performance difference *after optimisation* - and if there is a performance difference it will have nothing to with *lvalue* vs *rvalue* and everything to do with the temporary storing and returning the original value. – Tony Delroy Jul 03 '15 at 01:46
  • One is slower than the other because one makes a _copy_ of the original value while the other does not. – Captain Obvlious Jul 03 '15 at 01:47