On Mon, Oct 8, 2012 at 6:21 PM, Maciej Stachowiak <m...@apple.com> wrote: > On Oct 8, 2012, at 5:28 PM, Adam Barth <aba...@webkit.org> wrote: >> 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: >>>> >>>> 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. > > You can expect that we'll collect and share some data as the work progresses. > The fact is that we don't have really great data to share yet, we are still > in an exploratory phase. If you have any past data to share, we'd love to > look at it.
Unfortunately, I don't have the data from our previous experiments anymore. > One preliminary finding of ours is that different web pages fairly often load > identical resource bodies from different URLs. We expect possible benefits > from sharing the body data of resources in memory even if we cannot share the > URL or response headers. > > You can also expect that we won't push forward blindly on this effort if data > ultimately shows it to be a bad idea, or in general not worth the complexity. As I mentioned in bugs.webkit.org, we did our experiments a number of years ago, and it's certainly possible that the web has changed (e.g., social widgets have gained a lot of popularity in the intervening time). Maybe we should run some experiments as well and reconsider Chromium's approach. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
