It looks like MessagePort.postMessage() always routes through the browser process when sending messages. This has a number of issues: 1) Increased latency (on my machine this takes about 8x longer to deliver a message via a MessagePort vs something like Window.postMessage(). 2) Extra data copies - we can't do a zero-copy data transfer with Transferrable Objects if everything is marshaled to the browser process. This wasn't a big deal back when the primary use of MessagePort was talking to SharedWorkers (which live in their own process) but now that we're moving SharedWorkers into the parent renderer process, we should once again look at improving this.
Feb 19 2014,
firstname.lastname@example.org for the fyi
Feb 19 2014,
Jul 16 2015,
Aug 11 2015,
Do we have numbers about how much impact this could have? Anyways this looks like one of nice-to-have optimizations, though priority is probably not high.
Aug 12 2015,
As I mentioned in comment #1, it takes about 8x longer to deliver a message using our current scheme vs Window.postMessage() which doesn't round-trip to the browser process. Again, not a huge deal I think - the only case I could imagine this making a difference is if you had a large number of back-and-forth messages (where you send a message and wait for a reply before sending the next one) using a MessagePort - your throughput would be significantly limited by having to do the round trip out of process.
Aug 13 2015,
#5- Oh I see, thanks. Yeah esp. for same-process transfer with Transferable Objects I can imagine it will have huge difference.
Dec 17 2015,
I migrated an application that relied on `window.postMessage()` as a polyfill for `setImmediate` to WebWorkers. Now, it uses a MessagePort for the same purpose (sending a message to itself), and I noticed a large (~30%) decrease in overall performance compared with the window.postMessage() approach. The profile pointed to 40+% of time spent in (program), and the timeline profile showed noticeable gaps between MessagePort messages. I would greatly appreciate a fix for this, especially since WebWorkers are ideal for this style of high-throughput workload otherwise!
Mar 22 2016,
Apr 7 2016,
This is definitely something we'd need if issue 31666 doesn't get fixed soon. Right now we have to keep a significant portion of our logic in the main UI thread, instead of offloading it to a "controller worker". Since a worker cannot create sub workers, the only alternative is to have workers created in the main windows, and communicate with each other through entangled MessagePorts. Since we have to transfer large amounts of ArrayBuffer, we cannot use that workaround.
Mar 14 2017,
I think this issue has been resolved via the solution for issue 361001 . I observe about a 10x increase in throughput for in-process messaging now.
Mar 14 2017,
This is great, thanks Darin!
Sign in to add a comment