[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Adam Barth]

On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson <beidson at apple.com> wrote:
> On Oct 8, 2012, at 12:17 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson <beidson at apple.com> wrote:
>>> On Oct 8, 2012, at 11:24 AM, Adam Barth <abarth at webkit.org> wrote:
>>>> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson <beidson at apple.com> wrote:
>>>>> On Oct 8, 2012, at 10:58 AM, Adam Barth <abarth at webkit.org> wrote:
>>>>>> When we looked at whether we should add a shared memory cache to
>>>>>> Chromium, we came to the conclusion that there wasn't much benefit to
>>>>>> having a shared memory cache.  In
>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=98541#c4>, you mentioned that
>>>>>> you have data showing that a shared memory cache is a win.  Would you
>>>>>> be willing to share this data with the WebKit community?
>>>>>
>>>>> It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring.
>>>>>
>>>>> WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on.
>>>>>
>>>>> We don't have hard data to share at this time.  A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them.
>>>>
>>>> Without data showing that this is a win, adding a shared memory cache
>>>> to WebCore seems like over-engineering and unneeded complexity.  We
>>>> had the same design instincts as you when we looked at this issue in
>>>> Chromium, but we studied the issue (twice actually) and concluded that
>>>> the complexity wasn't worth the meager benefits.
>>>
>>> There might be some misunderstanding of the specifics of what I'm working on.
>>>
>>> I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of "shared memory" directly to WebCore.
>>>
>>> I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2.
>>>
>>> Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients.
>>>
>>> I'm not sure that I see how this case is in a different category.
>>
>> Would there be any design or implementation constraints on WebCore?
>> For example, would WebCore need to understand any concurrency or
>> performance issues caused by the memory being shared between
>> processes?
>
> For now we think the answer is no, or that any parts that do need to be concerned to be wholly encapsulated within the support for the client model.

Ok.  If there are no design implications for WebCore, then I don't
have a problem with this work continuing.

Based on my experience with this topic in Chromium, I believe you're
over-engineering, but if you're unwilling to share your data, I doubt
further discussion with cause either of us to change our minds.

Adam