Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 4 of 4
  1. #1
    Senior Coder jmrker's Avatar
    Join Date
    Aug 2006
    Location
    FL
    Posts
    3,091
    Thanks
    38
    Thanked 498 Times in 492 Posts

    Question Any differences in loop increment method?

    The following code results in the exact same output.
    Is there an advantage to using i++ over ++i (or visa-versa) in the loop?

    Code:
    <script type="text/javascript">
    var tarr1 = [];  for (var i=0; i<10; i++) { tarr1.push(i); }
    var tarr2 = [];  for (var i=0; i<10; ++i) { tarr2.push(i); }
    alert(tarr1.join(',')+'\n'+tarr2.join(','));
    </script>
    Similar question for the increment method in the following:
    Code:
    <script type="text/javascript">
    var tarr1 = []; var i=0;  do { tarr1.push(i); i++; } while (i<10);
    var tarr2 = []; var j=0;  do { tarr2.push(j); ++j; } while (j<10);
    alert(tarr1.join(',')+'\n'+tarr2.join(','));
    </script>
    Last edited by jmrker; 09-02-2011 at 04:54 AM.

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,965
    Thanks
    79
    Thanked 4,429 Times in 4,394 Posts
    No.

    And with modern C/C++/Java compilers it makes very very little difference (at most one machine instruction) in *any* circumstance.

    More than likely, the same is true of JavaScript, but I can't swear to it.

    The ONLY time it makes a difference is when you *use* the result of the increment (or decrement) in an expression.

    Such as:
    Code:
    <script type="text/javascript">
    var tarr1 = []; var i=0;  do { tarr1.push(i++); } while (i<10);
    var tarr2 = []; var j=-1;  do { tarr2.push(++j); } while (j<9);
    alert(tarr1.join(',')+'\n'+tarr2.join(','));
    </script>
    It is *conceivable* that the second loop will execute faster.

    Here's why: When you use post-increment, the language specification says "the value of the expression is the value *before* the increment, so the increment must not be visible to the consumer of the expression". (Or words to that effect, depending on what spec your read.)

    Whereas with pre-increment, the value is incremented and *then* used in the expression.

    The machine code for PRE-increment is quite simple:
    Code:
    loadregister A from i
    increment A
    storeregister A into i
    call push( ) [the register is the argument to the push function]
    But with POST-increment, at the machine code level, that means the compiler needs to generate something like this:
    Code:
    loadregiste A from  i
    call push() function 
    loadregister A from  i
    increment A
    storeregister A into i
    One extra machine instruction, to reload the register so it can be incremented and stored.

    And back when I was generating code for a C compiler for Z-80 processors (an 8 bit CPU! The biggest register held only16 bits), that's pretty much what we had to do.
    But with today's CPUs, their instruction set is so rich that they *probably* can generate code such as this:
    Code:
    /* implemient push[i++] */
    load i in A
    call push() function
    incrementMemoryLocation i
    versus
    Code:
    /* implemient push[++i] */
    incrementMemoryLocation i
    load i in A
    call push() function
    So in actuality there may very well be zero difference in performance. But even in the worst case, it's no more than 1 or possibly 2 machine instructions different.

    **********

    NOW... all that was for a *pure* compiler. One that compiles your source code down into machine language. So far as I know, no current JavaScript engine does that. Instead, they compile the JavaScript source into an intermediate tokenized form (in fact, that's what compliant JAVA compilers do!) and then a run-time engine "interprets" the intermediate tokens when the code runs. In consequence, JavaScript is much much slower than true compiled languages. And I can't predict what the effect of pre vs. post increment is for the different JS engines. Were I *guessing*, I'd guess that it is more like that old C compiler of ours. One or two "tokens" of difference and so a few extra machine cycles for post-increment.

    NOTICE THAT NONE OF THIS APPLIES to any of the code that you showed!! Because none of your code "consumed" the value of the incremented variable as part of some larger expression. So in all cases, all the compiler has to do is generate a single increment. And even a not-too-smart compiler will recognize that the two operations are identical in semantics in this case.

    [If you are curious: I said that JAVA compilers create an internal tokenized form--the so-called "byte code"--as do all of the MS ".NET" languages. The difference in those languages is that they then have an additional compilation stage--usually called a Just In Time compiler or "JIT" (pronounced just as spelled, with a short "i")--that then renders the byte code into machine code. By writing compilers this way, all the HARD work of smart code generation is the same, done when creating the byte code. And you only have to write a specific "JIT" for each separate CPU architecture.]
    Last edited by Old Pedant; 09-02-2011 at 06:01 AM.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    Senior Coder jmrker's Avatar
    Join Date
    Aug 2006
    Location
    FL
    Posts
    3,091
    Thanks
    38
    Thanked 498 Times in 492 Posts
    Thanks for the information.

    I had noticed you often used the pre-fixed version of the loop
    and I was accustomed to using the other.

    I was interested as to why when I saw no difference in the actual effect.

  • #4
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,965
    Thanks
    79
    Thanked 4,429 Times in 4,394 Posts
    Habit.

    Plus because of my compiler experience I learned to use pre unless post is really needed.

    The need to do so today is so much less than it was in 1979 (yeah, that's when I wrote the code generator for that C compiler for an 8-bit machine) that even "habit" isn't a good reason. But that's all I have.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •