New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 28 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 344814: MessagePorts should be more efficient if the entangled port is in the same process

Reported by atwilson@chromium.org, Feb 19 2014 Project Member

Issue description

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.
 

Comment 1 by ericbidelman@chromium.org, Feb 19 2014

Cc: sorvell@chromium.org
sorvell@chromium.org for the fyi

Comment 2 by kinuko@chromium.org, Feb 19 2014

Cc: horo@chromium.org

Comment 3 by nhiroki@chromium.org, Jul 16 2015

Cc: nhiroki@chromium.org

Comment 4 by kinuko@chromium.org, Aug 11 2015

Status: Available
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.

Comment 5 by atwilson@chromium.org, 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.

Comment 6 by kinuko@chromium.org, 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.

Comment 7 by ninten...@gmail.com, 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!

Comment 8 by nhiroki@chromium.org, Mar 22 2016

Components: Blink>Messaging

Comment 9 by mathieu....@gmail.com, 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.

Comment 10 by darin@chromium.org, Mar 14 2017

Owner: darin@chromium.org
Status: Fixed (was: Available)
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.

Comment 11 by kinuko@chromium.org, Mar 14 2017

This is great, thanks Darin!

Sign in to add a comment