4 ms·

What do you mean by the, "edge-case of an implementation... makes its way into programmers' habits" as something that happens a lot in javascript. Maybe I'm not

by swang 11y ago

What do you mean by the, "edge-case of an implementation... makes its way into programmers' habits" as something that happens a lot in javascript. Maybe I'm not understanding but I read that statement and I don't see how that applies to javascript.

Klathmon 11y ago
For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt) This might be a bad example, i'm honestly not sure how try/catch performs in other engines, i just know it deopts in V8. But the fact that i don't know if it's a javascript thing or a V8 thing speaks to my point.
- louislaf 11y ago
  It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra.
- bzbarsky 11y ago
  try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown. So yes, this is an excellent example.
dsp1234 11y ago
Since node.js is backed by V8, optimization decisions that the V8 team have made end up in developer code that runs in node.js. For example, Bluebird has a list of "optimization killers"[0] that many developers that I know use as a reference when making node.js libraries. However, these optimizations are V8 only, and so "edge-case of an implementation makes its way into programmers' habits". A quick example is "5.1. The key is not a local variable:", which ends up with having to jump through some hoops in a for-in loop, not because it's easy or because the language forces it, but just because V8 is the engine. [0] - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
- mraleph 11y ago
  > optimization decisions that the V8 team have made Optimization decisions that V8 team have made are much more universal than it might seem. It is true there are sometimes strange artificial corner cases - but those are often either bugs or temporary solutions that are going to be replaced with something more generic as soon as they start to hurt too much code. > which ends up with having to jump through some hoops in a for-in loop Could you clarify which hoops precisely do you need to jump through? I am not sure I can imagine a reasonable chunk of code that strives to be both fast, well written and wants to use a context captured or global for-in variable. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } How often do you write code like this?
  - dsp1234 11y ago
    Optimization decisions that V8 team have made are much more universal than it might seem. That's certainly possible, but maybe a competing VM can do better, but finds that everyone has coded specific V8 optimizations. They may be hesitant to push out their implementation. It may be a better optimization, but it causes existing code to run slower on their VM. Thus back to the original statement that implementation quirks find their way into developer code. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't). It's easy to end up sending the prop variable through a closure accidentally. Some real world examples[0][1][2]. Note that the solution requires pushing out to another function just to get around the deopt. With the sproutcore example being very clear, as they made the change specifically to satisfy the V8 VM. [0] - https://github.com/paperjs/paper.js/issues/466 https://github.com/paperjs/paper.js/issues/466 [1] - http://www.html5rocks.com/en/tutorials/performance/mystery/ http://www.html5rocks.com/en/tutorials/performance/mystery/ [2] - https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md https://github.com/sproutcore/sproutcore/blob/master/CHANGEL... (search "Removes V8 "ForIn is not fast case" warning")
    - mraleph 11y ago
      > The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't) Sure! I am just trying to say that in my opinion whenever you have a non-local variable used as iteration variable in for-in then you most probably have a bug in your code. I tried to illustrate this with an global variable example because it's a common source of JS bugs - when people leak things into a global namespace by accident. > Some real world examples[0][1][2] These links refer to a different bailout reason --- "ForIn is not fast case". The original ForIn support in Crankshaft (written coincidentally by me) only supported this kind of for-in because it was the important case to support and the one where you can get good performance with reasonable investment of time. Given time and bug reports from people hitting this bailout I would certainly extend ForIn support to cover a more generic case (assuming that supporting more generic case would make some code faster), however just in a couple of months after I landed this initial support I switched to a different project, so I never had chance to revisit this. This bailout reason is actually not in V8 anymore - as now V8 supports both fast and slow cases in Crankshaft[1] [1] https://github.com/v8/v8/blob/master/src/crankshaft/hydrogen.cc#L5318-L5349 https://github.com/v8/v8/blob/master/src/crankshaft/hydrogen...

by swang 11y ago

Klathmon 11y ago

For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt) This might be a bad example, i'm honestly not sure how try/catch performs in other engines, i just know it deopts in V8. But the fact that i don't know if it's a javascript thing or a V8 thing speaks to my point.

louislaf 11y ago
It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra.
bzbarsky 11y ago
try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown. So yes, this is an excellent example.

dsp1234 11y ago

Since node.js is backed by V8, optimization decisions that the V8 team have made end up in developer code that runs in node.js. For example, Bluebird has a list of "optimization killers"[0] that many developers that I know use as a reference when making node.js libraries. However, these optimizations are V8 only, and so "edge-case of an implementation makes its way into programmers' habits". A quick example is "5.1. The key is not a local variable:", which ends up with having to jump through some hoops in a for-in loop, not because it's easy or because the language forces it, but just because V8 is the engine. [0] - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...

mraleph 11y ago
> optimization decisions that the V8 team have made Optimization decisions that V8 team have made are much more universal than it might seem. It is true there are sometimes strange artificial corner cases - but those are often either bugs or temporary solutions that are going to be replaced with something more generic as soon as they start to hurt too much code. > which ends up with having to jump through some hoops in a for-in loop Could you clarify which hoops precisely do you need to jump through? I am not sure I can imagine a reasonable chunk of code that strives to be both fast, well written and wants to use a context captured or global for-in variable. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } How often do you write code like this?
- dsp1234 11y ago
  Optimization decisions that V8 team have made are much more universal than it might seem. That's certainly possible, but maybe a competing VM can do better, but finds that everyone has coded specific V8 optimizations. They may be hesitant to push out their implementation. It may be a better optimization, but it causes existing code to run slower on their VM. Thus back to the original statement that implementation quirks find their way into developer code. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't). It's easy to end up sending the prop variable through a closure accidentally. Some real world examples[0][1][2]. Note that the solution requires pushing out to another function just to get around the deopt. With the sproutcore example being very clear, as they made the change specifically to satisfy the V8 VM. [0] - https://github.com/paperjs/paper.js/issues/466 https://github.com/paperjs/paper.js/issues/466 [1] - http://www.html5rocks.com/en/tutorials/performance/mystery/ http://www.html5rocks.com/en/tutorials/performance/mystery/ [2] - https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md https://github.com/sproutcore/sproutcore/blob/master/CHANGEL... (search "Removes V8 "ForIn is not fast case" warning")
  - mraleph 11y ago
    > The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't) Sure! I am just trying to say that in my opinion whenever you have a non-local variable used as iteration variable in for-in then you most probably have a bug in your code. I tried to illustrate this with an global variable example because it's a common source of JS bugs - when people leak things into a global namespace by accident. > Some real world examples[0][1][2] These links refer to a different bailout reason --- "ForIn is not fast case". The original ForIn support in Crankshaft (written coincidentally by me) only supported this kind of for-in because it was the important case to support and the one where you can get good performance with reasonable investment of time. Given time and bug reports from people hitting this bailout I would certainly extend ForIn support to cover a more generic case (assuming that supporting more generic case would make some code faster), however just in a couple of months after I landed this initial support I switched to a different project, so I never had chance to revisit this. This bailout reason is actually not in V8 anymore - as now V8 supports both fast and slow cases in Crankshaft[1] [1] https://github.com/v8/v8/blob/master/src/crankshaft/hydrogen.cc#L5318-L5349 https://github.com/v8/v8/blob/master/src/crankshaft/hydrogen...