4 ms·
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 h
by TheLoneWolfling 11y ago
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:
Also:
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:
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;
}
not optimizable to remove the whole business with L and the if check?
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.)
- mraleph 11y ago> Why does this require JS (to the point of giving a blank page!) for something that can be trivially done without? This is a slide deck (not a blog post or article) hence its dependence on JS. (though even blog posts I write usually depend on JS to provide proper syntax highlighting and diagrams) > 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. If you don't know where `throwConcurrentModificationError(arr)` goes then you don't know what it does, e.g. it can do something like this: H.throwConcurrentModificationError = function (arr) { arr.push(10); }; (contrary to its name - but JITs don't optimize based on names) That's why JIT has to assume global side effects from the `throwConcurrentModificationError` call - unless of course it emits an unconditional deoptimization right before it which is what happens in the (0, o.f)() case.
- jimktrains2 11y ago> This is a slide deck (not a blog post or article) hence its dependence on JS. That makes it acceptable to not fail gracefully?
- SixSigma 11y agoYes. If I'm doing a presentation using a known browser why do I care about your failures.
- scintill76 11y agoBecause you might end up sharing the URL with people who don't have your "known browser", like the very situation that is prompting this complaint. I get it, whining about graceful degradation and being anti-Javascript can be annoying, but your response is even more so.
- SixSigma 11y agoNo, no, no. Do the right thing for now, not some mythical "what if" situation later that adds premature complification. One should argue that OP should re-write the whole thing in non-slide deck format - TTRWTF
- scintill76 11y agoOK, that's a pretty good point. I still stand by mine as a reasonable, not overly-complicated design goal if I were making a general slides viewer.
- jimktrains2 11y ago> One should argue that OP should re-write the whole thing in non-slide deck format - TTRWTF There are many CSS and JS-based slide decks that degrade nicely. e.g. deck.js (http://imakewebthings.com/deck.js/introduction/deck.html http://imakewebthings.com/deck.js/introduction/deck.html).
- 11y ago