3 ms·

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.

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.)

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.)