On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson <beid...@apple.com> wrote: > On Oct 8, 2012, at 12:17 PM, Adam Barth <aba...@webkit.org> wrote: >> On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson <beid...@apple.com> wrote: >>> On Oct 8, 2012, at 11:24 AM, Adam Barth <aba...@webkit.org> wrote: >>>> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson <beid...@apple.com> wrote: >>>>> On Oct 8, 2012, at 10:58 AM, Adam Barth <aba...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
