Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Object Literal Extension Performance #1820

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

Object Literal Extension Performance #1820

kpdecker opened this issue Jun 25, 2015 · 4 comments
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue

Comments

@kpdecker
Copy link
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.
@sebmck
Copy link
Contributor

sebmck commented Jun 25, 2015

  1. See Computed properties should use Object.defineProperty #357 for the issue that lead to the current Object.defineProperty behaviour.
  2. What other way is there?

@kpdecker
Copy link
Contributor Author

  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.

@sebmck sebmck closed this as completed in 0b1ce6c Jun 25, 2015
sebmck added a commit that referenced this issue Jun 25, 2015
@sebmck
add missing computed loose test - ref #1820
128d3b5
@sebmck
Copy link
Contributor

sebmck 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
Copy link
Contributor Author

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.

@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Jul 15, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kpdecker @sebmck