6 ms·

Generators in Firefox now 22 times faster

231 points by jsnell 12y ago

barbudorojo 12y ago
The author shows a micro benchmark in which the state of the generator is a single variable and discuss the history of generators from the first tier (interpreter code) to the second tier (using the Jit). Perhaps some more complete examples with should be analyzed since the case discussed here seems to be the simplest and so the 22 times faster perhaps doesn't hold except in very simple cases.
- lucian1900 12y ago
  The benchmark is mostly superfluous anyway. It's enough for me to know that generators no longer bail out to the interpreter.
amelius 12y ago
Of course generators are completely unusable until other browsers start to support them. That is, unless you use a compiler to convert your generator code into more mundane javascript [1]. It would be nice to see these "emulated generators" in the comparison too. [1] https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/
- fthrow111 12y ago
  Firefox uses javascript internally, so it's still good for Firefox devs and extension authors.
- rictic 12y ago
  Generators will be on by default (not behind a flag) in Chrome 39, which will be released to stable in the next couple of weeks I believe. https://www.chromestatus.com/feature/4959347197083648 https://www.chromestatus.com/feature/4959347197083648
  - amelius 12y ago
    But what about IE?
    - niutech 12y ago
      IE is lagging behind, as usual. See the HTML5 Test.
      - mbrubeck 12y ago
        html5test.com doesn't include generators or other JS language features. Instead, see http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
      - Flow 12y ago
        I think it's disappointing that Safari lags behind as much as IE does. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
      - dmethvin 12y ago
        That's not true. If you look at http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ you'll see IE11 preview (their "canary") has more green than any other browser including Chrome or Firefox. Yes, even more than Firefox nightly or Chrome canary.
        magicalist 12y ago
        > their "canary" while that's sort of true, the big distinction is that the features in their "canary" aren't going to hit "stable" for another year or so, which is a lot of iterations of Firefox and Chrome in the meantime. However, it is fantastic to see where they're headed with IE12.
    - acdha 12y ago
      Under consideration currently – go vote: https://status.modern.ie/generators https://status.modern.ie/generators
- tracker1 12y ago
  I only partially agree here... in this generation of apps, you're going to wind up using traceur or es6ify for the most part, unless you're building a bundled app that targets a browser shell (cordova, node-webkit, etc) that can make the option available. I'm actually slightly annoyed that I have to run the dev version of node and the --harmony flag to get the new JS options server-side... but seeing what co/koa do with generators is really nice... I'm stuck transforming my client-side scripts for a while... it will be nice when I don't need to browserify/es6ify anymore.
hartator 12y ago
Nowadays, every time!, I am hearing some news about Firefox getting better, I feel that's a lie. I feel Firefox is actually getting worse and worse, from disappointment to disappointment. Either when it's a new feature or new UI modifications (I loved to have a separation between the URL and the Google search != Chrome), or new web services (Mozilla "Labs"?), or new dev. tool (Firefox inspector is at best full of small bugs and seems to be an ugly copy and paste from Firebug). Hopefully the Mozilla CEO being fired will make things better but I feel now being mediocre it's new culture trend @ Firefox.
- tracker1 12y ago
  I'm not sure I completely agree... Honestly, there are many developers each working on stuff they are either required to do, or want to do. The only time I find the unibar in chrome annoying is when I'm searching for something specific to google... and effectively have to type google twice (first time sets the search site to google). As for the developer tools, I do wish it was closer to either the chrome dev tools or firebug myself, it looks too much like the IE10+ tools, which I find annoying. But that's a matter of preference. This is a matter of raw performance, not a subjective UI.. FF has made a lot of effort into improving JS at its' core... Chrome has worked to expanding the DOM in interesting ways. IE has taken a pragmatic approach to refining what comes from both, though having their own issues. The browser ecosystem today is so much better than it has ever really been, and I couldn't be happier about it. You can relatively easily create your own skin against a Firefox base. AFAIK it's still all XUL wrapped around a web view, and pretty easy to get into, admittedly last time I tried was 6+ years ago. Chrome is still my favorite browser, but I do appreciate what the others are doing... the best ideas do get copied, and it works.
- ibrahima 12y ago
  Uh, I still have separate URL and search bars, what are you talking about?
- realusername 12y ago
  I feel exactly the opposite, I've downloaded the Developer Edition which they released a few days ago and I've never seen a browser so fast, it feels much faster than chrome on my machine, I can't wait to have all the beta improvements merged into the standard version !
general_failure 12y ago
On an aside: what javascript really needed was async/await instead of generators. I have no clue why something as abstract as generators is being pushed. I mean the bane of javascript is the whole async programming with callbacks. Instead of solving the specific problem, this solves some problem which I don't see most apps having. Can someone in the know how care to explain?
- thezilch 12y ago
  generator = async yield = await Also, async/await themselves have a proposal accepted into ES7: https://github.com/lukehoban/ecmascript-asyncawait https://github.com/lukehoban/ecmascript-asyncawait
  - mcav 12y ago
    Yeah, but only in the most trivial sense. Generators are a very, very poor substitute for proper yield support, just as they were when Python devs used them in Twisted.
  - general_failure 12y ago
    From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generators. For example, var data = await downloadSomething(); function *downloadSomething() { // check somethings return await http.get('foo.com', function (result) { yield result; }); } The above won't work since the callback to http.get is not a generator. You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback. Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
    - munificent 12y ago
      > My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.
deleted 12y ago
[deleted]

231 points by jsnell 12y ago

The author shows a micro benchmark in which the state of the generator is a single variable and discuss the history of generators from the first tier (interpreter code) to the second tier (using the Jit). Perhaps some more complete examples with should be analyzed since the case discussed here seems to be the simplest and so the 22 times faster perhaps doesn't hold except in very simple cases.

lucian1900 12y ago
The benchmark is mostly superfluous anyway. It's enough for me to know that generators no longer bail out to the interpreter.

amelius 12y ago

Of course generators are completely unusable until other browsers start to support them. That is, unless you use a compiler to convert your generator code into more mundane javascript [1]. It would be nice to see these "emulated generators" in the comparison too. [1] https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/

fthrow111 12y ago
Firefox uses javascript internally, so it's still good for Firefox devs and extension authors.
rictic 12y ago
Generators will be on by default (not behind a flag) in Chrome 39, which will be released to stable in the next couple of weeks I believe. https://www.chromestatus.com/feature/4959347197083648 https://www.chromestatus.com/feature/4959347197083648
- amelius 12y ago
  But what about IE?
  - niutech 12y ago
    IE is lagging behind, as usual. See the HTML5 Test.
    - mbrubeck 12y ago
      html5test.com doesn't include generators or other JS language features. Instead, see http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
    - Flow 12y ago
      I think it's disappointing that Safari lags behind as much as IE does. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
    - dmethvin 12y ago
      That's not true. If you look at http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ you'll see IE11 preview (their "canary") has more green than any other browser including Chrome or Firefox. Yes, even more than Firefox nightly or Chrome canary.
      - magicalist 12y ago
        > their "canary" while that's sort of true, the big distinction is that the features in their "canary" aren't going to hit "stable" for another year or so, which is a lot of iterations of Firefox and Chrome in the meantime. However, it is fantastic to see where they're headed with IE12.
  - acdha 12y ago
    Under consideration currently – go vote: https://status.modern.ie/generators https://status.modern.ie/generators
tracker1 12y ago
I only partially agree here... in this generation of apps, you're going to wind up using traceur or es6ify for the most part, unless you're building a bundled app that targets a browser shell (cordova, node-webkit, etc) that can make the option available. I'm actually slightly annoyed that I have to run the dev version of node and the --harmony flag to get the new JS options server-side... but seeing what co/koa do with generators is really nice... I'm stuck transforming my client-side scripts for a while... it will be nice when I don't need to browserify/es6ify anymore.

hartator 12y ago

Nowadays, every time!, I am hearing some news about Firefox getting better, I feel that's a lie. I feel Firefox is actually getting worse and worse, from disappointment to disappointment. Either when it's a new feature or new UI modifications (I loved to have a separation between the URL and the Google search != Chrome), or new web services (Mozilla "Labs"?), or new dev. tool (Firefox inspector is at best full of small bugs and seems to be an ugly copy and paste from Firebug). Hopefully the Mozilla CEO being fired will make things better but I feel now being mediocre it's new culture trend @ Firefox.

tracker1 12y ago
I'm not sure I completely agree... Honestly, there are many developers each working on stuff they are either required to do, or want to do. The only time I find the unibar in chrome annoying is when I'm searching for something specific to google... and effectively have to type google twice (first time sets the search site to google). As for the developer tools, I do wish it was closer to either the chrome dev tools or firebug myself, it looks too much like the IE10+ tools, which I find annoying. But that's a matter of preference. This is a matter of raw performance, not a subjective UI.. FF has made a lot of effort into improving JS at its' core... Chrome has worked to expanding the DOM in interesting ways. IE has taken a pragmatic approach to refining what comes from both, though having their own issues. The browser ecosystem today is so much better than it has ever really been, and I couldn't be happier about it. You can relatively easily create your own skin against a Firefox base. AFAIK it's still all XUL wrapped around a web view, and pretty easy to get into, admittedly last time I tried was 6+ years ago. Chrome is still my favorite browser, but I do appreciate what the others are doing... the best ideas do get copied, and it works.
ibrahima 12y ago
Uh, I still have separate URL and search bars, what are you talking about?
realusername 12y ago
I feel exactly the opposite, I've downloaded the Developer Edition which they released a few days ago and I've never seen a browser so fast, it feels much faster than chrome on my machine, I can't wait to have all the beta improvements merged into the standard version !

general_failure 12y ago

On an aside: what javascript really needed was async/await instead of generators. I have no clue why something as abstract as generators is being pushed. I mean the bane of javascript is the whole async programming with callbacks. Instead of solving the specific problem, this solves some problem which I don't see most apps having. Can someone in the know how care to explain?

thezilch 12y ago
generator = async yield = await Also, async/await themselves have a proposal accepted into ES7: https://github.com/lukehoban/ecmascript-asyncawait https://github.com/lukehoban/ecmascript-asyncawait
- mcav 12y ago
  Yeah, but only in the most trivial sense. Generators are a very, very poor substitute for proper yield support, just as they were when Python devs used them in Twisted.
- general_failure 12y ago
  From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generators. For example, var data = await downloadSomething(); function *downloadSomething() { // check somethings return await http.get('foo.com', function (result) { yield result; }); } The above won't work since the callback to http.get is not a generator. You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback. Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
  - munificent 12y ago
    > My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.

deleted 12y ago

[deleted]