"This is because the synchronization needs to occur over a low-throughput, queue-based IPC subsystem, accompanied by resource-intensive and unpredictably timed context switches mediated by the operating system. To understant [sic] the scale of this effect, we looked at the latency of synchronous, cross-document DOM writes and window.postMessage() roundtrips."
Web pages running in different Chrome renderer processes can only communicate using postMessage. WebKit's design makes it practically impossible to access DOM or JS objects across different processes or threads (the only browser that can do this as IE -- top level browsing contexts have run in different threads in IE since the beginning).
You can test this hypothesis by creating two same-origin documents in different processes. In the first window, do window.name="foo"; then in the other, do window.open("javascript:;", "foo").document.documentElement.innerHTML="hello"; this will work in every browser except Chrome.
Chrome actually provides a way for web developers to explicitly allow a window.open invocation to create a new renderer process (see http://code.google.com/p/chromium/issues/detail?id=153363 ). This way, the author can allow Chrome to use a new process if they don't need access to the popup beyond postMessage.
So, I have no idea where that peak 800 millisecond DOM access latency came from, but it's not from IPC across renderer processes. I'd love to see the benchmark that was used to get that number.
The circumstance I described that Chrome doesn't support is very rare in real-world web pages. It's pretty unusual to use window.open to get a JS reference to an existing window, and not supporting that makes Chrome's renderer process model much much simpler. So, it's a reasonable trade-off.
TL;DR: Chrome does a good thing. This blog post is written by someone who is not well informed.
It makes it simpler, but does it also make it slower? Seemed that the blog's point was that communicating between windows is slower in chrome than in other browsers because of this behavior. You simply further explained why, and confirmed that it is only in chrome. Right?
Now, I do think there is room for argument that this is a better way. But you do not seem to be undermining any of the blog's points. Those being that chrome has a slower process to communicate between windows, and that it is the only browser that does this. The frequency with which this is needed was not a point of contention.
The author claims that windows in different processes communicate slowly in Chrome.
My claim is that windows in different processes cannot communicate at all in Chrome. Only same-process windows can communicate -- and that refutes the author's claim that IPC slows down cross-window/frame communication in Chrome.
Hmm... interesting. I was honestly under the impression that all tabs (or windows) were separate processes. Are you saying that if you call window.open with a same domain that a new process is not started? (Sadly, I don't have chrome handy to test this right off.)
That's right -- Chrome uses the same process when there is a JS reference between the windows.
(In addition, Chrome will sometimes make windows/tabs share a process if there are a lot of tabs open, to save memory. There is a limit to the total number of render processes that Chrome will have.)
Cool, thanks. I am, not shockingly, curious how this works, now. Is it just a hinting mechanism, or can the rendering process of a tab/window change on the fly? What happens when you go to a new url in an opened tab? (I mean these more as things I'm now interested in. Maybe I'll get off my virtual butt and check the source. Granted, that source tree is less than casually approachable.)
Web pages running in different Chrome renderer processes can only communicate using postMessage. WebKit's design makes it practically impossible to access DOM or JS objects across different processes or threads (the only browser that can do this as IE -- top level browsing contexts have run in different threads in IE since the beginning).
You can test this hypothesis by creating two same-origin documents in different processes. In the first window, do window.name="foo"; then in the other, do window.open("javascript:;", "foo").document.documentElement.innerHTML="hello"; this will work in every browser except Chrome.
Chrome actually provides a way for web developers to explicitly allow a window.open invocation to create a new renderer process (see http://code.google.com/p/chromium/issues/detail?id=153363 ). This way, the author can allow Chrome to use a new process if they don't need access to the popup beyond postMessage.
So, I have no idea where that peak 800 millisecond DOM access latency came from, but it's not from IPC across renderer processes. I'd love to see the benchmark that was used to get that number.