propagateContextChange visits all child fibers

[intellild]

propagateContextChange in the current context implementation visits all child fibers rather than fibers that have dependency on the context.
In my case, there may be thousands of child components and 99% of them don't have dependency on the context, which causes propagateContextChange spends a lot of scripting time but eventually does 'nothing'.

[gaearon]

It visits all fibers because that's its purpose — to find the ones that depend on context. There are some ways we're planning to optimize the algorithm but they'll need significant refactors so don't count on them happening soon. For now, it's essentially bruteforce by design.

However, it is possible that there might be some ways to optimize the function itself. It could very well be possible that it has become slower since the initial implementation due to some accidental deopt or compiler behaivor. So if you want to make a synthetic benchmark to stress-test it, and look for optimization opportunities, that would be appreciated.

[intellild]

@gaearon I can have a try. There are two versions of files in react-resonciler(old.js and new.js). Which should I modify?

[gaearon]

Not sure which ones you'll get on build.. Try changing both and see which gets used?

[intellild]

I opened a draft pull request #20786
Improvements are significant. I use https://github.com/intellild/react-context-performance for profiling.
This implementation uses a 32bit number as a bitset. If there are more than 32 contexts, it falls back to the current logic.
Choices are:

• Keep the 32bit number, only 32 contexts are optimized
• Implement a Hash Array Mapped Trie style "HashSet" which can be highly optimized for this scenario.
• Use bigint
  If a HashSet or bigint are used, it is possible to remove the propagateContextChange. Instead, we can check contexts while reconciler walking down the tree.

before

after

[intellild]

I noticed that the bubbleProperties spent a lot of time on my branch. It seems that I missed something related to bailouts.

[gaearon]

Thanks for the PR! I don't think this approach would work for us because then you have a performance cliff as soon as you have more than 32 contexts. We generally prefer predictable performance over "fast in some cases", because otherwise seemingly small changes can have disproportionate impact on the whole application, and it becomes very difficult to debug perf problems.

[intellild]

After some rethinking, it seems a number array is good enough, since there won't be large number of contexts. I will have a try later

[gaearon]

since there won't be large number of contexts

This is not correct; we should expect that a large app (which is where this optimization is most needed) will have a large number of contexts.

[gaearon]

By the way, originally I referred to optimizing in terms of optimizing the brute force traversal itself. It's quite likely that there might be some engine deopts there, e.g. due to how GCC compiles code. So it would be good to look into the compile output and if there are ways to optimize it.

[intellild]

large number of contexts

I mean thousands of contexts. One number supports 32 contexts and a number array with length 32 supports 32 * 32 contexts. That's 1024 contexts and 32 is only one tree node size of a hash tree. Thus I believe this is quite enough to optimize the scenario and a hash tree is not necessary.

[intellild]

I checked the output of production build and closure compiler did a great job.

I tried the array method and it works fine although the implementation is not correct. Will this get merged ? I will finish it if it would get merged

[markerikson]

@intellild my guess is probably not, given that Andrew is already working on #20646 and #20890 .

[intellild]

@markerikson Thanks. I read the PR and it seems they are not conflicting

[markerikson]

Hmm. Well, if it doesn't conflict there might be a chance, but that'd really be an @acdlite kind of question.