4 ms·
"This is because the synchronization needs to occur over a low-throughput, queue-based IPC subsystem, accompanied by resource-intensive and unpredictably timed
by dbloom 14y ago
"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 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.
- taeric 14y agoMy reading has notoriously sucked lately, but it reads like you are strengthening the blog's point. Is that right?
- dbloom 14y agoThe 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.
- fastest963 14y agoGrooveshark falls back on doing this in their third-party callbacks: window.opener = window.open('', clientWindow);
- taeric 14y agoIt 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.
- dbloom 14y agoThe 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.
- taeric 14y agoHmm... 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.)
- dbloom 14y agoThat'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.)