Webworkers

[SanderSpies]

There has been discussion about webworkers before, @petehunt made already an implementation and @sebmarkbage has some ideas on how he wants to accomplish it within the current code base. If I remember correctly, React should not just run in a webworker but both in the "main thread" and a webworker.

So, what are we waiting for? @sebmarkbage would be great if you could give a more detailed outline of your ideas so we can get this moving :-).

[sophiebits]

See https://github.com/reactjs/react-future/tree/master/05%20-%20Workers.

[SanderSpies]

So I'm currently thinking of taking the following steps:

• implement prerender as a function of ReactClass
• implement createCallbackElement next to createElement which initially just returns an empty dummy element that can be updated by the webworker
• create a WebWorker wrapper component (<WebWorker />)
• optimize render call with using prerender

Not exactly sure yet about:

• starting webworkers (wonder what the performance penalties are)
• syncing UI changes
• dealing with events
• passing React inside the webworker, perhaps it should be something smaller?
• deal with non-webworker browsers

Feedback wanted :-)

[sebmarkbage]

@cecilemuller The problem of just using the DOM is that you can no longer integrate with synchronous APIs. So you have to build high level wrapper APIs on the main thread. IMO, the best way of building high level APIs on the main thread is to build them as React components that expose asynchronous APIs. Which is why I think that the solution is react->react rendering.

@SanderSpies The top section requires invasive changes to the core but we're working on doing them anyway. What we need help with is all the basic stuff.

• How do you start the worker?
• How do you load modules in a worker?
• How do you determine the root to render into?
• How do we unit test the system?

[SanderSpies]

How do you start a worker?
For now I can see the following solutions for this problem:

• separate file that includes only what is necessary for the worker, which would require extra build steps
• create a worker on the fly (blob), which will not work in every browser and I expect would have performance penalties. Also resolving dependencies here for the worker is going to be painful - if not impossible without extra build steps.
• start the entire build in multiple workers, still this would still require the usage of a build tool

So yeah, for now I don't see this working without a build tool. My preference would go to the first one.

How do you determine the root to render into?
I would expect the "main" React to always start in the main thread, and components leaving stubs in this thread to which they can write when they want to. Of course writing to the DOM still needs to be done via the normal React reconciliation mechanism.

It should be possible to have a single worker which is used for multiple components, which makes it a bit more challenging. Probably an extra id needs to be given to communicate to the right component.

How do we unit test the system?
If you would be testing a render function, it would initially only show the webworker stubs - and testing the result of a webworker would be something different. Something like a callback for a webworker result could work here (waitFor(webworkerId) comes to mind).

If there are other options here or I'm missing something, I would definitely like to hear it!

[mathew-kurian]

What progress has been made towards this?

[sophiebits]

@bluejamesbond None explicitly for web workers, though we've done a lot of refactoring recently with the goal of making it possible to have multiple reconcilers and make things more serializable, which helps with this goal.

[pfrazee]

Any new work in this area?

[sophiebits]

No, same as my last message.

[pfrazee]

Ok. I may be able to work on this later. Are there technical blockers, or is it just a matter of getting the code written?

[axemclion]

I wrote a custom renderer for ReactJS using Web Workers to try and get some performance numbers. Here is the demo page and the repo.

I noticed that for small applications, the cost associated with postMessage seems to make the WebWorker approach slower than using React-dom. For applications like DBMonster when the number of nodes is high, this pays off. The performance also depends on the batching the messages when sent between the web worker and the main UI thread and the batch size needs to be chosen carefully.

Here is the detailed analysis.

[jimfb]

@axemclion Thanks for the writeup, that's pretty cool! Your writeup mentioned that the bottle neck appears to become the mutations on the UI thread. Presumably this is because you are mutating the values in every row as frequently as possible, but this is obviously not representative of real-world use cases. It is my belief that most rerenders result in very few changes (That is, the majority of a typical application remains unchanged from one frame to the next). Under the assumption that a typical rerender would do a lot of "work" (calculating diffs) but affect a small number of dom nodes, I wonder if batching becomes less significant and the overall performance benefits of running in a worker become more evident. Especially with respect to things like scroll performance while running a rerender in the background.

[axemclion]

@jimfb You are right about the real world use case - most of the time, there would be expensive dom-diffing, but would result in very little change to the browser DOM. The batching would still be an interesting problem since postMessage seems to be another issue.

In the experiment, when I set the batch size to 1 (i.e.) just call postMessage for every DOM mutation, the speed is worse than when setting the batch size to something a little bigger (say 10 or 50).

I think there is scope for some clever batching, where the UI thread handing the DOM mutations tells us how long those mutations take, and based on that the worker determines the batch size. This way, we don't send so many mutations that we take more than 16ms, or too less that we start building a backup.

For scroll, I also tried running the DOM mutations in a requestAnimationFrame, and that did seem to make it better.

[pfrazee]

Forgive me if this is an obvious suggestion, but have you tried benchmarking transferrable objects?

[axemclion]

@pfraze That is a good idea, i could try that. Converting DOM mutations into transferrable objects may be hard though.

[axemclion]

@pfraze I tried transferrable objects, and more simply, just use JSON.stringify - the perf is actually pretty good. It continues to stay that way (better than react-dom), even as the number of objects increase. I am currently running the tests on my machines and will post out the results.

Thanks for the suggestion :)