Why does this require JS (to the point of giving a blank page!) for something that can be trivially done without? A bit of tweaking to the source later, and I have something readable. Now, about the actual article:<p>Also:<p>Can someone explain to me why it has to assume that arr.length could change? It states it does, but I don't see why. That seems like a pretty obvious optimization flaw: you should be able to safely assume that something won't change if the only cases where it could change is if it already has changed. In other words, why is this:<p><pre><code> var sum = 0;
for (var i = 0, L = arr.length;
i < arr.length;
++i) {
if (arr.length !== L)
H.throwConcurrentModificationError(arr);
var item = list[i];
sum += item;
}
</code></pre>
not optimizable to remove the whole business with L and the if check?<p>Also, this is one of my frustrations with optimizers in general. Far too many of them end up with global (or at the very least) side-effects of trivial changes (or worse, changes that shouldn't do anything!), to the point of making optimization a fool's game. (I optimized this method, but now the change in function alignment changes cache aliasing such that the program runs slower. Hey look: A runs substantially faster than B. But if you add a comment here, B runs faster than A.)
This was a very, very interesting and entertaining slide deck. Thanks for taking the time to make this.<p>The angry face you use reminded me a lot of Ally Brosh's style and made me laugh out loud.<p>Love this style.
o.f() and (0, o.f)() have different semantics - the latter is closer to temp = o.f; temp().<p>For that reason the optimisers see the code being function-call vs. method-call. Given the usage of function and method calls are generally different the compilers make different optimising decisions.