4 ms·

The only significantly sub-optimal example is the first one, which is labeled as such. And it isn't particularly unintuitive that computing the upper bound of

The only significantly sub-optimal example is the first one, which is labeled as such. And it isn't particularly unintuitive that computing the upper bound of the loop on each iteration is going to slow down the computation. Also, none of the methods are actually wrong. These are code optimizations. You can find tricky little code optimizations in any language. And in compiled languages you also have compiler optimizations that you can apply if you really need to squeeze out more performance. It's not fair to say that it's a pitfall of the language that this is possible. Some better examples of javascript having unintuitive pitfalls would involve things like triple equals, for...in and hasOwnProperty, or semi-colon insertion, or function scope (as opposed to block scope) or .... well there are a lot. But most of the time the reason they are unintuitive is because the intuition we are relying on comes from other languages. They are not javascript. If you take the time to actually learn javascript as its own language it turns out to be a pretty decent language to work with.

Chris_Newton 15y ago
And it isn't particularly unintuitive that computing the upper bound of the loop on each iteration is going to slow down the computation. Also, none of the methods are actually wrong. These are code optimizations. That may be true, but the optimization you're talking about is only necessary if: (a) a language's semantics aren't expressive enough to guarantee that the length of the array won't change in mid-iteration, and (b) the language's runtime environment can't optimize away the repeated look-up on the fly, having determined that nothing within the loop actually is updating the length of the array even if such a change is permitted by the rules of the language. Both of these things are properties of JavaScript, or at least the particular implementation(s) of JavaScript where the optimization is required. While this sort of detail isn't an absurdly bad idea in the way that, say, semicolon insertion turned out to be, I don't think it's reasonable to say they are somehow not negative points for JavaScript. Many other languages can and do handle similar situations in better ways.
- grannyg00se 15y ago
  First, let me throw in the obligatory "don't optimize prematurely" suggestion here. I think it probably fits well in this for loop "optimization" discussion. As for your points a and b, I believe some implementations (V8 comes to mind) actually do handle this optimization for you indicating that the language isn't preventing it. People are free to come up with a better js runtime, just as people are free to come up with their own compilers for other languages. You're going to get some variation depending on what language constructs you use with a particular compiler and its compile-time settings. "Both of these things are properties of JavaScript, or at least the particular implementation(s) of JavaScript where the optimization is required." So if I build a particular implementation and you run your code on it and find your code running horribly, you'll blame javascript?
  - romaniv 15y ago
    As for your points a and b, I believe some implementations (V8 comes to mind) actually do handle this optimization for you indicating that the language isn't preventing it. The language isn't mandating it either. Therefore, anyone working with the language will be forced to deal with multiple obscure optimizations and with different language implementations. Loops are just one example. JS is choke-full of similar issues.
    - Chris_Newton 15y ago
      Exactly. Optimisations like this are a least common denominator problem, in that to some extent you have to cater for the worst runtime that your code is likely to run on, even if other runtimes would do a better job without needing your help. As for the premature optimisation comment made by grannyg00se above, I am very wary of applying that logic here. We're talking about an obvious potential inefficiency that is actively being introduced if we choose to write a for-loop in a certain way that most of us are used to. As the original article demonstrates, there are many other ways we could write that loop without that inefficiency, so I think this is more a case of not introducing unnecessary overhead when there's no good reason for it. (We don't know it's going to be an inefficiency in practice, but assuming it won't be is essentially a Sufficiently Smart Compiler argument.)

Chris_Newton 15y ago

And it isn't particularly unintuitive that computing the upper bound of the loop on each iteration is going to slow down the computation. Also, none of the methods are actually wrong. These are code optimizations. That may be true, but the optimization you're talking about is only necessary if: (a) a language's semantics aren't expressive enough to guarantee that the length of the array won't change in mid-iteration, and (b) the language's runtime environment can't optimize away the repeated look-up on the fly, having determined that nothing within the loop actually is updating the length of the array even if such a change is permitted by the rules of the language. Both of these things are properties of JavaScript, or at least the particular implementation(s) of JavaScript where the optimization is required. While this sort of detail isn't an absurdly bad idea in the way that, say, semicolon insertion turned out to be, I don't think it's reasonable to say they are somehow not negative points for JavaScript. Many other languages can and do handle similar situations in better ways.

grannyg00se 15y ago
First, let me throw in the obligatory "don't optimize prematurely" suggestion here. I think it probably fits well in this for loop "optimization" discussion. As for your points a and b, I believe some implementations (V8 comes to mind) actually do handle this optimization for you indicating that the language isn't preventing it. People are free to come up with a better js runtime, just as people are free to come up with their own compilers for other languages. You're going to get some variation depending on what language constructs you use with a particular compiler and its compile-time settings. "Both of these things are properties of JavaScript, or at least the particular implementation(s) of JavaScript where the optimization is required." So if I build a particular implementation and you run your code on it and find your code running horribly, you'll blame javascript?
- romaniv 15y ago
  As for your points a and b, I believe some implementations (V8 comes to mind) actually do handle this optimization for you indicating that the language isn't preventing it. The language isn't mandating it either. Therefore, anyone working with the language will be forced to deal with multiple obscure optimizations and with different language implementations. Loops are just one example. JS is choke-full of similar issues.
  - Chris_Newton 15y ago
    Exactly. Optimisations like this are a least common denominator problem, in that to some extent you have to cater for the worst runtime that your code is likely to run on, even if other runtimes would do a better job without needing your help. As for the premature optimisation comment made by grannyg00se above, I am very wary of applying that logic here. We're talking about an obvious potential inefficiency that is actively being introduced if we choose to write a for-loop in a certain way that most of us are used to. As the original article demonstrates, there are many other ways we could write that loop without that inefficiency, so I think this is more a case of not introducing unnecessary overhead when there's no good reason for it. (We don't know it's going to be an inefficiency in practice, but assuming it won't be is essentially a Sufficiently Smart Compiler argument.)