Pre-increment vs. Post-increment: Which is Faster for 3D Software Development?

By Kevin Tatterson

It was fun writing my first two blog posts – because I like pushing people’s buttons with controversial, philosophical subjects.  But for this article, I’d like to get technical.

Pre-increment vs. Post-increment in 3D Software Development

I was asked recently, “Did you know that pre-increment was faster than post-increment?”  I answered, “No”.  The claim:

                                                            ++d is faster than d++

The explanation:  the implementation of post-increment (d++) must create a temporary storage for housing the original value of d, increment/store d, and return the original temporary value.  In contrast, pre-increment (++d) only has to increment/store the value and return it – no temporary required. 

To put things in programming speak, suppose we implement our own integer class and implement the overloads for pre and post-increment:

class myint

{

       int n;

public:

       myint( int _n ): n(_n) {}

       myint( const myint & m )

       {

              n = myint.n;

       }

       myint& operator++()  // prefix, e.g., ++n

       {

n = n + 1;

return n;
}

       myint operator++(int) // postfix, e.g., n++

{

       myint m(*this);      // create the temporary

       n = n + 1;

       return m;

}

};

On the surface – it is clear that post-increment is doing more work – because it has to “create the temporary”.  But is it measurable?  Let’s look at this through a couple different lenses.

Lense #1:  basic types

More than one person has studied this and all have found the same conclusion:  for basic types (int, double, etc.), ++d has the same performance as d++.  I’ve seen a couple good studies that break things down right to the exact assembly instructions.  Here’s a good study.  

Lense #2:  really simple objects

The “myint” class above is a good example of a “really simple object”.  Essentially, the goal of the design is to mimic an integer type – yet allow control over the precise implementation of each operator overload – in particular, the ones we want to measure:  pre-increment and post-increment.

Suppose we put myint’s pre-increment and post-increment under the empirical microscope – and try to measure the performance difference.  Here’s the program:

clock_t start;

       const int iters = 800000000;

       {

              myint m(0);

              start = clock();

              for ( int i = 0; i < iters; i++ )

                     m++;

              printf( "post incr time: %d\n ms", clock() - start );

       }

       {

              myint d(0);

              start = clock();

              for ( int i = 0; i < iters; i++ )

                     ++d;

              printf( "pre incr time: %d ms\n", clock() - start );

       }

The first problem we run into is the compiler optimizer.  As written above, the Microsoft VS 2005 compiler optimizer completely optimizes the loop away, avoiding it altogether!  This defeats our desire to measure the overhead cost of pre- vs. post-increment.

One low-cost trick to “calm” the optimizer is to add a __asm nop block to the implementations of our pre- and post-increment methods.  The biggest downside to this approach is that the __asm  directive prevents the optimizer from inlining – and for our “really simple object”, this can make a big difference.  Let’s get back to the inlining issue later – for now, here’s what the __asm nop code looks like:

       myint& operator++()  // prefix, e.g., ++n

       {

              __asm { nop }

n = n + 1;

return n;
}

       myint operator++(int) // postfix, e.g., n++

{

              __asm { nop }

       myint m(*this);      // create the temporary

       n = n + 1;

       return m;

}

With the __asm nop blocks in place, we can start to run some benchmarks.  Repeated runs converge on the following times:

post incr time: 1781 ms

pre incr time: 1515 ms

This means pre-increment is 15% faster than post-increment.  But is it believable?  Let’s look at the generated assembly and compare clock cycles:

The assembly instructions shown above are the exact instructions being timed – and hence, represent the cost of each iteration of the loop.  The performance improvement based on total clocks:  14.3%.  This compares nicely to the empirical data, 15%.

Next Post:

I will push this a little into the theoretical (with respect to inlining), then tear it all down with a just a small dose of reality.