-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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.
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
perf: match ownKeys perf to the one of objectSpread #10189
perf: match ownKeys perf to the one of objectSpread #10189
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/11092/ |
d5f8af0
to
49f8d4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 (especially the comment!)
Thanks! (As a side note, I really like having more ✔️ than usual!) EDIT: I was going to merge this PR, I'll wait for CI to finish. |
The idea comes from discussion with @nicolo-ribaudo |
This PR addresses a performance regression introduced at #10171.
Object.keys
returns a list of enumerable property names. Hence we filterenumerable
only on the property symbols. Note that this approach is also practiced inhelpers.objectSpread
.In practice the most frequent use cases of objectSpread is merging two plain objects, which means we can skip a sweep of already enumerable property names. I also drafted a jsPerf snippet on the performance difference. It is 10% faster on V8 75 when merging two object with 512 keys.