2 ms·

As I said: The only case that arr.length could change, and hence the if statement taken, is if the if statement had already been taken - i.e. arr.length had al

As I said: The only case that arr.length could change, and hence the if statement taken, is if the if statement had already been taken - i.e. arr.length had already changed. This seems safe to optimize. It doesn't matter what H.throwConcurrentModificationError is - it can only be called iff it has already been called. Which means that as soon as you're through the first loop iteration, you know that arr.length hasn't changed that loop, and it won't change any other iterations through the loop. And as for JS - there are plenty of slide decks that work perfectly fine without, or at the very least degrade gracefully. So that's not a good excuse.

mraleph 11y ago
> The only case that arr.length could change, and hence the if statement taken, is if the if statement had already been taken - i.e. arr.length had already changed. Fair point. I misread your original comment. To see this you need a more sophisticated analysis pass than V8 is capable of performing - something similar in spirit to sparse conditional constant propagation, V8's LICM just assumes that all blocks are reachable so it takes the union of all possible side-effects. > So that's not a good excuse. I am not making an excuse, I am simply stating a fact: this is a slide deck, it needs JS to operate. As simple as that. If there is an easy fix - please send me a PR[1], I will gladly take it [1] https://github.com/mraleph/mraleph.github.com/tree/master/talks/goto2015 https://github.com/mraleph/mraleph.github.com/tree/master/ta...