React Context value propagation performance

[alexreardon]

Hi there!

I have observed a performance issue with context providers and value updates. I have spoken with @gaearon with this on twitter, so he will have a bit more context

Let's say you have a provider:

const CounterContext = React.createContext(1);
const Provider = ContextContext.Provider

And you update the value to the provider

render() {
  return (
    return <Provider value={this.state.value}>{this.props.children}</Provider>
  )
}

All good so far.

Let's say you want to pass this value down the tree, but for performance reasons you do not want to render the tree. The only components you want to render are your consumer components (in our case CounterContext.Consumer)

A naive way would be to do something like this:

class Blocker extends React.Component {
  shouldComponentUpdate() {
    return false;
  }
  render() {
    return this.props.children;
  }
}

// ...

render() {
  return (
    <Provider value={this.state.value}>
	 <Blocker>
          {this.props.children}
     </Blocker>
    </Provider>
  )
}

Even though no components in the tree are rendered except for the consumers, the update itself is very expensive. I suspect that the tree walking algorithm takes a while to run.

Standalone example

https://codesandbox.io/s/61jnr811kr

This example has about a 20-30ms render time for a simple counter update. In a production app with a list of 500 nodes (~500 * 10 components, 5000 components) we were looking at update times similar to that of rendering the tree (150ms+)

A bit more context

I was trying to replace react-redux with a root StateProvider that would create a subscription to a store and pass the latest state into the context. The consumers would then pick up this update, run a selector, and re-render if the result value had changed. I had this all working in react-beautiful-dnd but I found the updates through the context itself was too slow for usage (You can see the relevant files here and here)

[trueadm]

I looked into this and running your CodeSandbox example with production mode flags makes the update time take around ~1ms for me: https://codesandbox.io/s/7kw8qozz9x.

Did you try running with the production flags to see if your performance issue went away? Looking into the development bundle, 10ms of the time taken seems to be due to performance.measure markers being really bad for performance (something the React team has already found in the past).

[gaearon]

Looks like @alexreardon might be assuming

import "react/cjs/react.production.min.js";
import "react-dom/cjs/react-dom.production.min.js";

import React from "react";
import ReactDOM from "react-dom";

would switch on production mode — I don't think that's correct.

That said I'd still appreciate if @trueadm could look into this locally with a prod build (and maybe less performance.now calls). In our previous discussion with @alexreardon he said these issues occur in prod builds too even without measurements.

[trueadm]

@gaearon I added them in (well Ivan did) after I asked how to enable production mode on CodeSandbox and this was the recommended way for now. I'll keep digging into the issue though and see if something comes up.

[alexreardon]

The issue still existed, to a reduced amount, with production builds. In the real world example I listed (500 item list), the time to hit all the consumers was still taking 20-30ms with production builds. Compare this against something like react-redux which uses an event emitter to pass values down a tree, where the cost to hit a consumer is ~0ms

[alexreardon]

I made the codesandbox after to illustrate the issue and i did not try to get that working with production builds

[markerikson]

This would kinda be a big deal for React-Redux, actually, because we're trying to switch to using createContext in version 6 instead of having all connected components be separate subscribers.

This does also tie into the performance benchmarks we've been trying to do with our WIP branches as well.

[alexreardon]

I can try to gather more numbers if that helps. I thought the sandbox showed the issue enough. If more clarity is needed, I can try to obtain more numbers

[markerikson]

Yes, I'd certainly appreciate any further details we can gather on this.

I'm also curious whether observedBits comes into play with this at all. If consumers are marked with bitmasks that shouldn't require an update, does React still have to traverse the entire tree, or does that speed things up?

[gaearon]

Sandbox isn't helpful by itself because it doesn't run in production mode and includes sandbox-specific overhead (e.g. they inject code into every loop to check if it's infinite).

To get these issues sorted, we'll definitely need repro cases as plain HTML files working against UMD production builds of React and ReactDOM.

@markerikson Let's leave observedBits out of this for now, I think it derails the issue a little bit. The issue is specifically about the default update performance, and if there's some extra overhead we'd want to look at it regardless of opt-in optimization APIs. In fact talking about these APIs here distracts us from fixing the bigger issue because it's tempting to say "we just need this opt-in thing to fix it".

[trueadm]

Yeah, a self-contained HTML version using UMD builds would be a big help. I noticed also that there's another ReactDOM being used to render the CodeSandbox UI and that probably affected profiling a bit too.

[alexreardon]

I did a bit more digging. It turns out things are not as bad as I first observed, which is good! I must have been tested against dev builds at some point.

Tip: if you want to run the codesandbox examples locally as a React developer you can just copy paste it into babel-standalone/dev in the React repo. Then you can run it against your own custom builds of React (cheers @gaearon for the tip)

I have simplified my real world use case for clarity. You can find it here:

branch: state-provider-simplier (it will not allow parent renders through at all so reordering is broken, but it simplifies the use case)

Results (with production build of React 16.5.2):

• with react-redux and critical render: ~3ms
• using Context and critical render: ~5m

(a 40% slow down)

Critical render: when dragging an item we only render that Draggable and not the rest of the tree

Which sort of makes sense at face value. Context updates walk the tree, whereas react-redux has a direct subscription so its state update propigation is closer to 0ms.

It looks like context updates would be sufficient for most* use cases. Although it is a significant slowdown from an event emitter model.

For react-beautiful-dnd we would push for extremely fast updates, so a 2ms => 40% slow down is still significant for us

[alexreardon]

This is relevant for react-redux @markerikson as moving to leaning on context for propigating state values would lead to a slow down over the current subscription pattern

[theKashey]

Look like a zero-subscription-cost model, used in Context API, is not absolutely free.