[webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

[Maciej Stachowiak]

On Jan 11, 2013, at 12:21 AM, Adam Barth <abarth at webkit.org> wrote:

>> 
>> If you're actually planning to make a significant complexity-imposing architectural change for performance reasons, without any way to test whether it delivers the claimed performance benefits, or how it compares to less complex approaches, then why should any rational person agree with that approach? When attempting to improve performance, the burden of proof is on the person proposing the performance improvement, not on others to create a test to figure out if the performance improvement works. It's not valid to respond to a request for performance testing info with the equivalent of "patches welcome".
> 
> Is that really the case?  If so, I'm surprised that the patches for
> the shared memory cache and the NetworkProcess landed.  I raised
> similar questions to the ones you're raising now, but the folks
> purposing those changes basically ignored me and landed their patches
> anyway.

NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial.

What I know is controversial, and I believe merits further follow-up discussion, is the choice of where proxying of networking to an outside process should hook in - whether at the ResourceHandle layer (as Chromium does it), or at the CachedResource layer, as WebKit2 is doing it. That choice involves hypotheses about both performance and appropriate architecture. I feel that the WebKit2 folks have not provided sufficient public data to fully justify the choice of where to hook things in, and I will encourage things to do so. On the other hand, Chromium folks historically did not really provide a lot of data or justification for why the ResourceHandle was the right place. Rather, it was presented as a "constraint" and a must-have for merging back to the WebKit repository.

Long term, it is obviously somewhat regrettable if we end up diverging on this point, and therefore having two different insertion points for proxying, as that makes WebKit overall more complex. 

I think your whitepaper on the topic was a good start on outlining some of the pros and cons. I commented on it a bit in email and via the comment system, but discussion died down (probably due to vacations and then the holidays).

Here it is for reference of others: <https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1>

In addition to my previous comments, I believe some topic not yet fully covered by your whitepaper are:
- Hooking in proxying at the ResourceHandle layer may require threading information through ResourceHandle that it logically should not need to know (if one thinks of it as a an abstraction on top of a low-level networking API), such as association with a specific frame/page, or 
- How to connect loading mechanisms that bypass ResourceHandle or otherwise bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs (currently implemented as a magic ResourceHandle subclass), etc. The two approaches have different architectural implications for this type of feature. I am not sure offhand which approach is cleaner or whether one way or the other has more pragmatic benefits.

I'll add also that it seems possible in principle to make all WebCore loading go through the CachedResource layer, jut as it's possible to have it all go through the ResourceHandle layer, and it's likely beneficial to do so though the benefits in cases of more marginal load types may be small.

Regards,
Maciej