Object Literal Extension Performance #1820

Closed
kpdecker opened this Issue Jun 25, 2015 · 4 comments

Projects

None yet

2 participants

@kpdecker
Contributor

Babel's performance is quite a bit lower than the ES5 equivalent.
http://kpdecker.github.io/six-speed/

Strict Babel was up to 83x slower and loose mode is up to 13x slower when testing in browser. Looking at the implementation I have two questions that I'm unsure of:

  1. What does the use of defineProperty provide over obj[x] = when using {value: value, enumerable: true, configurable: true, writable: true}?
  2. Are distinct operations vs a combination of object literal and assignment operations used in loose mode done this way to maintain the key iteration order of these objects?

Glad to look into PRs to change these but I want to make sure I am not missing a valid reason for things being the way they are before going this route.

@kittens
Member
kittens commented Jun 25, 2015
  1. See #357 for the issue that lead to the current Object.defineProperty behaviour.
  2. What other way is there?
@kpdecker
Contributor
  1. Was more to confirm that my assumption is correct. Only improvement I could see is to do object literals for all fields up to the first dynamic field and then switch to assignment operations.
@kittens kittens closed this in 0b1ce6c Jun 25, 2015
@kittens
Member
kittens commented Jun 25, 2015

The object literal initialiser actually does this for "spec" mode but not for loose mode. Just made it do it in loose mode. Released as of 5.6.7. Thanks for the suggestion!

@kpdecker
Contributor

Awesome, re-ran my six-speed tests and loose mode now has parity with the es5 impl (within 10%) as they are effectively the same thing now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment