-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
[performance] Replace hasOwnProperty in child processing with typeof undefined check #3665
Conversation
@@ -81,7 +81,7 @@ function mapSingleChildIntoContext(traverseContext, child, name, i) { | |||
var mapBookKeeping = traverseContext; | |||
var mapResult = mapBookKeeping.mapResult; | |||
|
|||
var keyUnique = !mapResult.hasOwnProperty(name); | |||
var keyUnique = ('undefined' === typeof mapResult[name]); |
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.
Normally we'd just write (mapResult[name] === undefined)
– I assume that's no slower?
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.
typeof
is about 20-25% faster than direct equality according to http://jsperf.com/hasownproperty-vs-in-vs-undefined/81
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.
We have a transpiler that can turn === undefined
into === void 0
which is faster yet but ugly.
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.
We use the constant (string literal) on the right hand side. Which is triggering a lint warning which is failing the unit tests.
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.
I'll update to match the styling rules.
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
I found many more places that we can replace |
Will this fail if I have a key named E.g. |
@sebmarkbage I'm not sure if we care enough, but we could create the object with |
@sebmarkbage - that was my first instinct too. It looks like by that point we're working with objects where key is |
Ah. Ofc. I think we even have a unit test for this so they should've caught it. This seems safe "enough" then. Just fix the lint? |
Btw, I doubt you would get noticeable results in a macro test. The reason this shows up in profiling tools is because tiny method calls gets exaggerated. When profile React I'd recommend measuring a larger operation yourself without a profiler and then compare it before/after this change. Normally we don't trust Profiler + JSPerf tests as trusted sources for optimizations. I don't think this change should hurt though so why not. |
@syranide |
@bloodyowl Creation of the object yes. |
@sebmarkbage Do you have any specific suggestions as far as benchmarking React rendering? I'm having a lot of trouble finding a consistent way to measure performance. Timing at the macro level is highly variable: some renders take 8ms some take 20ms which is why I chose to use benchmark.js around full renders to normalize it across many executions. Also, there are a lot of for...in + hasOwnProperty loops throughout the codebase that could be updated to use Object.keys and for loops. Should I submit these updates as a separate PR or include it here? |
We haven't used Object.keys in part due to worries about GC overhead. ReactDOMComponent.js has the other places that are likely to matter for perf. |
(I guess there are a few in ReactMultiChild.js too.) |
[performance] Replace hasOwnProperty in child processing with typeof undefined check
Thanks! |
hasOwnProperty
withinflattenSingleChildIntoContext
is showing up in the top of profiling so I ran an experiment with replacing it with a simple typeof === undefined check. Performance difference shown in Travis: https://travis-ci.org/mridgway/react-perf/builds/58356726