4 ms·

I’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in

I’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in every browser I tried. Hopefully having some better benchmarks gets Firefox and Chrome developers to also get to work on this.

hzoo 9y ago
Yeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know) Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.
franciscop 9y ago
Do you mean that you saw actual differences when using Javascript in a normal website? Or that they were slower than the alternatives in a synthetic benchmark? It would be really surprising that those were the performance bottlenecks.
- deleted 9y ago
  [deleted]
itslennysfault 9y ago
TypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations. Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.
pizlonator 9y ago
Native ES6 is faster in WebKit than polyfill/transpiled.
- jacobolus 9y ago
  Yes, but sticking to old-school Javascript features was dramatically faster than either.
  - pizlonator 9y ago
    Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.
    - netheril96 9y ago
      But ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.
      - pizlonator 9y ago
        I've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.
        saamyjoon 9y ago
        I agree too. I wonder if this has been discussed at TC39.
    - fenomas 9y ago
      To be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)? When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)
      - 9y ago
deecewan 9y ago
Pretty much the only thing I've had problems with is generators. Regenerator runtime is so slow. Especially when making a bunch of calls with async/await

hzoo 9y ago

Yeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know) Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.

franciscop 9y ago

Do you mean that you saw actual differences when using Javascript in a normal website? Or that they were slower than the alternatives in a synthetic benchmark? It would be really surprising that those were the performance bottlenecks.

deleted 9y ago
[deleted]

itslennysfault 9y ago

TypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations. Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.

pizlonator 9y ago

Native ES6 is faster in WebKit than polyfill/transpiled.

jacobolus 9y ago
Yes, but sticking to old-school Javascript features was dramatically faster than either.
- pizlonator 9y ago
  Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.
  - netheril96 9y ago
    But ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.
    - pizlonator 9y ago
      I've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.
      - saamyjoon 9y ago
        I agree too. I wonder if this has been discussed at TC39.
  - fenomas 9y ago
    To be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)? When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)
    - 9y ago

deecewan 9y ago

Pretty much the only thing I've had problems with is generators. Regenerator runtime is so slow. Especially when making a bunch of calls with async/await