7 ms·
High-Speed ES2015
- i336_ 10y agoTangential: the number of anonymous viewers (hovering around 50) is an amusing juxtaposition with the small "Proprietary" in the bottom-right corner of all the slides.
- shakna 10y agoAs much as these speed improvements to Node are awesome, and the team have been doing a great job... How is only a 1.2x speed regression acceptable? For... Syntactic sugar? [0] [0] https://docs.google.com/presentation/d/1wiiZeRQp8-sXDB9xXBUAGbaQaWJC84M5RNxRyQuTmhk/preview#slide=id.g1b84aeb97c_0_2 https://docs.google.com/presentation/d/1wiiZeRQp8-sXDB9xXBUA...
- espadrine 10y agoIt is explained on the previous slide. It looks like syntactic sugar, but it is actually a much more complex feature that involves iterators (which potentially requires several function calls if it is a user-defined iterator). And even with optimizations that detect when it is a well-known fundamental iterator (like an Array), you still have to pay for the detection (after all, you might have an eval that calls this function with a non-Array, and Array can be monkey-patched).
- rubber_duck 10y agoJS semantics are garbage both for writing code and for optimizations - and all new ES standards just keep piling on top instead of fixing it for fear of breaking backcompat. WASM with GC can't come soon enough.
- Touche 10y agoAnd yet JS is faster than most other dynamic languages. Pretty good garbage if you ask me.
- tfar 10y agoThat is not a sign of the quality of the language though. It is more a sign of how much money went into making a poor quality language perform well. Compare the speed of JS JIT VMs to Lua JIT VMs considering the investment respectively for example.
- Touche 10y agoIt is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole. Lua is better optimized because it is smaller. It's been the right decision to keep Lua small given where it specializes. Given where JavaScript specializes it's been the right decision to not keep it small but to evolve it. JavaScript is big because it can be big; it has the resources to make it so. You're wrong.
- tps5 10y ago> It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole. I think this is fundamentally wrong. I think you're confusing the language itself with how the language has been implemented. Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA. These days JS generally gets JIT compiled and a tremendous amount of work has gone into improving the popular compilers. Lots of tricks are involved. These tricks are quite clever (though sometimes inelegant) and result in significant speedups. But they have nothing to do with the language itself.
- jessaustin 10y agoSpeed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA. If so, you're basically agreeing with parent, in parent's disagreement with this from further upthread: JS semantics are garbage... for optimizations
- nfriedly 10y agoTo be fair, the slide deck says that the long-term goal is equal or faster performance vs ES5.
- arximboldi 10y agoI am very surprised with the stuff shown in this talk. One would think that by using a more explicit syntax, the compiler/interpreter has more context to optimize and do things faster. Looking at the destructuring example, it seems like part of the problem is that the new constructs are actually more general, since their semantics are defined in terms of iterators in order to support user defined types... I guess, on the other hand, this still allows for better overall system performance (e.g. one can now pass lazy-evaluated transformations instead of producting new arrays all the time when writing functional-style code.). An alternative would be to have sepparate syntax [a, b, c...] for arrays and (a, b, c...) for iterator based destructuring. There is the risk then that then everyone starts using the former syntax for the sake of premature optimization and we end up with over-restrictive API's that then disable the opportunities for lazy-evaluation and so on described before. Definitely and interesting case. It would be nice to be able to read some of the discussion of the standardization process and see how these performance trade-offs where considered. Anyone has some pointers?
- magicalist 10y ago> It would be nice to be able to read some of the discussion of the standardization process and see how these performance trade-offs where considered. Anyone has some pointers? There's the mailing list at https://esdiscuss.org/ https://esdiscuss.org/ More recently there's been more discussion around specific proposals in github repos under the tc39 org: https://github.com/tc39 https://github.com/tc39 And Rick Waldron takes TC39 meeting notes in this repo: https://github.com/rwaldron/tc39-notes https://github.com/rwaldron/tc39-notes
- chr1 10y agoi have followed many of discussion on esdiscuss and unfortunately they were not paying much attention to performance, all too often the argument was: we need to get semantics right, thinking about the performance is the job of browser makers:(
- jacobolus 10y agoThis is why I like just using coffeescript. Nicer syntax than ES6, with the same speed as optimized basic Javascript (because that’s what it compiles to).
- synthecypher 10y agoAny videos of this presentation would love to see them.
- sjrd 10y ago"We want you to help us! [...] Ideas for real ES2015 performance test suite." * Take a language that compiles to JS, with the option to target either ES5.1 features or ES2015 features. For example, Scala.js. * Take a macro-benchmark suite, or an application with measurable performance metrics, written in that language. For example, https://github.com/sjrd/scalajs-benchmarks https://github.com/sjrd/scalajs-benchmarks * Run the benchmarks when targeting ES5.1 (default in Scala.js) versus ES2015 (with `scalaJSOutputMode := OutputMode.ECMAScript6`) * Enjoy the slowdown :-p I did that 1.5 years ago when I was developing Strong Mode support for Scala.js (now defunct). Results were awful at the time: https://groups.google.com/d/msg/strengthen-js/Bfa_HPhVbiY/yM40rvnoP9kJ https://groups.google.com/d/msg/strengthen-js/Bfa_HPhVbiY/yM... They probably have improved since then; I should redo the benchmarks one of these days.