[performance] Replace hasOwnProperty in child processing with typeof undefined check

[mridgway]

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

[sophiebits]

Normally we'd just write (mapResult[name] === undefined) – I assume that's no slower?

[mridgway]

typeof is about 20-25% faster than direct equality according to http://jsperf.com/hasownproperty-vs-in-vs-undefined/81

[sebmarkbage]

We have a transpiler that can turn === undefined into === void 0 which is faster yet but ugly.

[sebmarkbage]

We use the constant (string literal) on the right hand side. Which is triggering a lint warning which is failing the unit tests.

[mridgway]

I'll update to match the styling rules.

[facebook-github-bot]

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 cla@fb.com. Thanks!

[facebook-github-bot]

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

[mridgway]

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]

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]

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

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

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]

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]

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

[syranide]

@bloodyowl Creation of the object yes.

[mridgway]

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

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]

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

[sophiebits]

Thanks!