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. Thanks, ~Brady > > Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
