3 ms·

18% speedup by replacing o.f() with (0,o.f)()

16 points by surganov 11y ago

olliej 11y ago
o.f() and (0, o.f)() have different semantics - the latter is closer to temp = o.f; temp(). 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.
- mraleph 11y ago
  Yes, you are absolutely right - semantics is quite different. But that's not what changes perf here - the difference comes from whether there is an explicit property load or a property load is an implicit part of the method call. This change is also made in the code that never executes during the benchmark run - which adds to a conundrum. There is a very V8 / Crankshaft specific thing going on here - slides try to explain it.
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 ago
      Yes. If I'm doing a presentation using a known browser why do I care about your failures.
      - scintill76 11y ago
        Because 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 ago
        No, 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
breakingcups 11y ago
This was a very, very interesting and entertaining slide deck. Thanks for taking the time to make this. The angry face you use reminded me a lot of Ally Brosh's style and made me laugh out loud. Love this style.

16 points by surganov 11y ago

o.f() and (0, o.f)() have different semantics - the latter is closer to temp = o.f; temp(). 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.

mraleph 11y ago
Yes, you are absolutely right - semantics is quite different. But that's not what changes perf here - the difference comes from whether there is an explicit property load or a property load is an implicit part of the method call. This change is also made in the code that never executes during the benchmark run - which adds to a conundrum. There is a very V8 / Crankshaft specific thing going on here - slides try to explain it.

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 ago
    Yes. If I'm doing a presentation using a known browser why do I care about your failures.
    - scintill76 11y ago
      Because 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 ago
        No, 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

breakingcups 11y ago

This was a very, very interesting and entertaining slide deck. Thanks for taking the time to make this. The angry face you use reminded me a lot of Ally Brosh's style and made me laugh out loud. Love this style.