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.

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

Merged
merged 2 commits into from
Apr 22, 2015

Conversation

mridgway
Copy link
Contributor

hasOwnProperty within flattenSingleChildIntoContext 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

@@ -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]);
Copy link
Collaborator

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?

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@facebook-github-bot
Copy link

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!

@facebook-github-bot
Copy link

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@mridgway
Copy link
Contributor Author

I found many more places that we can replace hasOwnProperty calls that may improve this as well, for instance a lot for...in loops.

@sebmarkbage
Copy link
Collaborator

Will this fail if I have a key named toString etc?

E.g. <div><span key="toString" /></div> will cause {}['toString'] !== undefined which will make it seem like this was a duplicate key.

@syranide
Copy link
Contributor

@sebmarkbage I'm not sure if we care enough, but we could create the object with Object.create(null) and fall back to hasOwnProperty only if that isn't supported (to be replaced with a proper Map in the future).

@zpao
Copy link
Member

zpao commented Apr 14, 2015

@sebmarkbage - that was my first instinct too. It looks like by that point we're working with objects where key is .$hasOwnProperty and .$toString and .2 for implicit keys.

@sebmarkbage
Copy link
Collaborator

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?

@sebmarkbage
Copy link
Collaborator

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.

@bloodyowl
Copy link
Contributor

@syranide Object.create(null) might just actually be worse in some cases (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1066878)

@syranide
Copy link
Contributor

@bloodyowl Creation of the object yes.

@mridgway
Copy link
Contributor Author

@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?

@sophiebits
Copy link
Collaborator

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.

@sophiebits
Copy link
Collaborator

(I guess there are a few in ReactMultiChild.js too.)

sophiebits added a commit that referenced this pull request Apr 22, 2015
[performance] Replace hasOwnProperty in child processing with typeof undefined check
@sophiebits sophiebits merged commit 3c66b8f into facebook:master Apr 22, 2015
@sophiebits
Copy link
Collaborator

Thanks!

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

Successfully merging this pull request may close these issues.

7 participants