Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 1:50 PM, Adam Barth aba...@webkit.org wrote: That raises the question of what the cache-size to hit-rate curve looks like. I don't think that's something we've ever measured for the MemoryCache, but it would be interesting to know, for example, whether increasing the cache size by 4% increases the cache hit rate by more or less than 4%. My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. The question you raise is ceratainly an interesting one to study to determine the optimum cache size, and to revisit when improvements are made to cache efficiency. But with respect to the proposed improvement under discussion: If you imagine this as a curve with hit rate on the Y axis and cache size required to achieve that hit rate on the X axis, then the potential improvement under discussion would shift the curve down (assuming the 4% redundancy level holds across the typical user's working set). In economic terms, you can think of this as shifting the supply curve down (more hit rate can be supplied at any given cost in memory), rather than movement along the supply curve. Which is pretty good for you regardless of your demand curve (your willingness to pay memory use for cache hit rate). Yes, but depending on the slope of the curve, you can be introducing all this complexity for, e.g., a 1% increase in the cache hit rate. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 10, 2012, at 8:49 AM, Adam Barth aba...@webkit.org wrote: On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 1:50 PM, Adam Barth aba...@webkit.org wrote: That raises the question of what the cache-size to hit-rate curve looks like. I don't think that's something we've ever measured for the MemoryCache, but it would be interesting to know, for example, whether increasing the cache size by 4% increases the cache hit rate by more or less than 4%. My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. The question you raise is ceratainly an interesting one to study to determine the optimum cache size, and to revisit when improvements are made to cache efficiency. But with respect to the proposed improvement under discussion: If you imagine this as a curve with hit rate on the Y axis and cache size required to achieve that hit rate on the X axis, then the potential improvement under discussion would shift the curve down (assuming the 4% redundancy level holds across the typical user's working set). In economic terms, you can think of this as shifting the supply curve down (more hit rate can be supplied at any given cost in memory), rather than movement along the supply curve. Which is pretty good for you regardless of your demand curve (your willingness to pay memory use for cache hit rate). Yes, but depending on the slope of the curve, you can be introducing all this complexity for, e.g., a 1% increase in the cache hit rate. If that's the slope, and someone (e.g. a vendor) doesn't like that tradeoff, they could take a 4% reduction in the cache size instead. (The curve is almost surely nonlinear so we're really talking about marginal slope at a given pre-existing cache size.) That's what I meant about shifting the curve down. It only fails to be worth it if neither a 4% reduction in the memory used by the cache nor the equivalent hit rate improvement nor any combination in between are worth it. The availability of the speed tradeoff can't make the change less worthwhile than if it was just a straight memory use reduction. I would be highly surprised if anyone sincerely finds it not worth it on either basis, particularly in case of vendors who target mobile devices with limited memory. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. FWIW, a few years back I did some in-depth data gathering on this score using real world websites. I found that, for encoded data, hit rate in the cache increased exponentially as cache size increased up to ~4MB, increased linearly as cache size increased above ~4MB, and increased not at all as cache size increased above ~100MB (since all resources that were eligible for caching and not expired were already in the cache). My guess is that the inflection points in the graph have moved out to ~8MB or ~16MB in the past few years. Note that these numbers do not correspond precisely to WebCore cache sizes, since the WebCore cache size includes both encoded and decoded data. Of course, the precise hit rates you'll see depend on the content you're browsing, and it's possible to hand-craft content that shows benefits up to arbitrarily large cache sizes, or shows no benefits down to arbitrarily small cache sizes. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak m...@apple.com wrote: 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. I did some preliminary profiling of this earlier. The data is not necessarily very representative of the web as whole, I simply browsed through a number of popular sites with an instrumented build ( https://bug-98539-attachments.webkit.org/attachment.cgi?id=167753). Here is what I had in the WebCore memory cache in the end: TOTAL duplicates count=443 size=852791 decodedSize=3426638 all cached resources count=2636 size=116463712 17% of cache entries are exact copies of previous entries. They use 4.3MB out of total 116MB cache size (4%). The average size of duplicate entries is much smaller than the average entry size (not surprisingly, transparent 1x1 images etc). Some examples: HTTP vs. HTTPS: hash=5d90af size=91556 decodedSize=34834 https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js hash=5d90af size=91556 decodedSize=32 http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js (decodedSize for js resources is the size of the function offset cache which can differ depending which functions have been parsed). Ad scripts with deliberately unique URLs: hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=76273718 ? hash=6f6494 size=3111 decodedSize=648 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=711567314 ? hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=908690779 ? hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=876087584 ? Same framework loaded by multiple unrelated sites: hash=230c7d size=1958 decodedSize=0 http://static.iltalehti.fi/js/measure/spring.js hash=230c7d size=1958 decodedSize=1536 http://yle.fi/global/spring/spring.js (didn't see as many of these as expected though i'm sure there are sites that run into this) Copy-paste resources: hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/features/search/css/bg/spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://images.apple.com/global/nav/images/globalsearch_spinner.gif Versioning: hash=cecbad size=184899 decodedSize=0 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/applestore-rs-2.css hash=cecbad size=184899 decodedSize=0 http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/applestore-rs-2.css hash=47a8de size=20041 decodedSize=7870 http://js.t.sinajs.cn/open/analytics/js/suda.js?version=b4d67909ad6b5b7d hash=47a8de size=20041 decodedSize=7870 http://tjs.sjs.sinajs.cn/open/analytics/js/suda.js Multiple content servers: hash=8e976b size=808 decodedSize=13088 http://i0.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif hash=8e976b size=808 decodedSize=71700 http://i3.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif Based on this I think this is definitely worth at least looking further. antti 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Tue, Oct 9, 2012 at 7:52 AM, Antti Koivisto koivi...@iki.fi wrote: On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak m...@apple.com wrote: 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. I did some preliminary profiling of this earlier. The data is not necessarily very representative of the web as whole, I simply browsed through a number of popular sites with an instrumented build (https://bug-98539-attachments.webkit.org/attachment.cgi?id=167753). Here is what I had in the WebCore memory cache in the end: TOTAL duplicates count=443 size=852791 decodedSize=3426638 all cached resources count=2636 size=116463712 17% of cache entries are exact copies of previous entries. They use 4.3MB out of total 116MB cache size (4%). The average size of duplicate entries is much smaller than the average entry size (not surprisingly, transparent 1x1 images etc). Some examples: HTTP vs. HTTPS: hash=5d90af size=91556 decodedSize=34834 https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js hash=5d90af size=91556 decodedSize=32 http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js (decodedSize for js resources is the size of the function offset cache which can differ depending which functions have been parsed). Ad scripts with deliberately unique URLs: hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=76273718? hash=6f6494 size=3111 decodedSize=648 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=711567314? hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=908690779? hash=6f6494 size=3111 decodedSize=32 http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=876087584? Same framework loaded by multiple unrelated sites: hash=230c7d size=1958 decodedSize=0 http://static.iltalehti.fi/js/measure/spring.js hash=230c7d size=1958 decodedSize=1536 http://yle.fi/global/spring/spring.js (didn't see as many of these as expected though i'm sure there are sites that run into this) Copy-paste resources: hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/features/search/css/bg/spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif hash=8fb3e size=3965 decodedSize=13088 http://images.apple.com/global/nav/images/globalsearch_spinner.gif Versioning: hash=cecbad size=184899 decodedSize=0 http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/applestore-rs-2.css hash=cecbad size=184899 decodedSize=0 http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/applestore-rs-2.css hash=47a8de size=20041 decodedSize=7870 http://js.t.sinajs.cn/open/analytics/js/suda.js?version=b4d67909ad6b5b7d hash=47a8de size=20041 decodedSize=7870 http://tjs.sjs.sinajs.cn/open/analytics/js/suda.js Multiple content servers: hash=8e976b size=808 decodedSize=13088 http://i0.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif hash=8e976b size=808 decodedSize=71700 http://i3.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif Based on this I think this is definitely worth at least looking further. This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses. Adam 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote: This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses. It is relevant when considering if and how to share cache data between processes. It is also interesting in single process case. Brady's refactoring should be helpful for both scenarios. antti Adam 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto koivi...@iki.fi wrote: On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote: This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses. It is relevant when considering if and how to share cache data between processes. It is also interesting in single process case. Brady's refactoring should be helpful for both scenarios. Content-addressable caches are quite interesting. There are a couple benefits you could hope to achieve: 1) Reduced memory usage by deduping cached values. The data you mentioned seems mostly about this benefit. 2) Reduced latency by finding increasing the cache hit rate for duplicated entries. This one is trickier without cooperation from the server because you don't know the hash of the resource until you've already received it. We've had a couple of customers ask about (2), but there are some tricky security problems because you end up leaking the identity of cross-origin resources in the timing channel. Aiming for (1) also carries some of that risk because you'll leak the identity of cross-origin resources in the cache eviction channel (which can be probed with timing or network traffic), but it's likely not as big a problem. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 9, 2012, at 1:24 PM, Adam Barth aba...@webkit.org wrote: On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto koivi...@iki.fi wrote: On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote: This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses. It is relevant when considering if and how to share cache data between processes. It is also interesting in single process case. Brady's refactoring should be helpful for both scenarios. Content-addressable caches are quite interesting. There are a couple benefits you could hope to achieve: 1) Reduced memory usage by deduping cached values. The data you mentioned seems mostly about this benefit. 2) Reduced latency by finding increasing the cache hit rate for duplicated entries. This one is trickier without cooperation from the server because you don't know the hash of the resource until you've already received it. We've had a couple of customers ask about (2), but there are some tricky security problems because you end up leaking the identity of cross-origin resources in the timing channel. Aiming for (1) also carries some of that risk because you'll leak the identity of cross-origin resources in the cache eviction channel (which can be probed with timing or network traffic), but it's likely not as big a problem. We're mainly interested in (1), with the corollary of greater cache effectiveness at equivalent total cache size (so you can think of the benefit as an indirect speed win rather than as just a memory win). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Tue, Oct 9, 2012 at 1:31 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 1:24 PM, Adam Barth aba...@webkit.org wrote: On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto koivi...@iki.fi wrote: On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote: This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses. It is relevant when considering if and how to share cache data between processes. It is also interesting in single process case. Brady's refactoring should be helpful for both scenarios. Content-addressable caches are quite interesting. There are a couple benefits you could hope to achieve: 1) Reduced memory usage by deduping cached values. The data you mentioned seems mostly about this benefit. 2) Reduced latency by finding increasing the cache hit rate for duplicated entries. This one is trickier without cooperation from the server because you don't know the hash of the resource until you've already received it. We've had a couple of customers ask about (2), but there are some tricky security problems because you end up leaking the identity of cross-origin resources in the timing channel. Aiming for (1) also carries some of that risk because you'll leak the identity of cross-origin resources in the cache eviction channel (which can be probed with timing or network traffic), but it's likely not as big a problem. We're mainly interested in (1), with the corollary of greater cache effectiveness at equivalent total cache size (so you can think of the benefit as an indirect speed win rather than as just a memory win). That raises the question of what the cache-size to hit-rate curve looks like. I don't think that's something we've ever measured for the MemoryCache, but it would be interesting to know, for example, whether increasing the cache size by 4% increases the cache hit rate by more or less than 4%. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
Hey, can you share your plan how to prioritize network requests in the network process? It's a long standing issue of the chromium port (and I believe the blackberry port is affected as well) that a ResourceRequest doesn't know whether it was created for e.g. an XHR or a main document load, which makes it difficult to prioritize the requests. We currently work around that issue by adding a TargetType to ResourceRequest which is however a layering violation which I'd like to get rid of. best -jochen On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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? Adam On Mon, Oct 8, 2012 at 10:39 AM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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. Thanks, ~Brady Adam On Mon, Oct 8, 2012 at 10:39 AM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 8, 2012, at 10:52 AM, Jochen Eisinger joc...@chromium.org wrote: Hey, can you share your plan how to prioritize network requests in the network process? … We currently work around that issue by adding a TargetType to ResourceRequest which is however a layering violation which I'd like to get rid of. Since the NetworkProcess management will be contained in WebKit 2 it won't be an equivalent layering violation for that port. If that explanation doesn't make sense then I might have misinterpreted your concern. On a slightly different note it seems reasonable to me that a WebCore ResourceRequest have target-type/priority-type information attached to it. I don't know if doing that has come up in the past and different conclusions we reached. I haven't placed a lot of thought into that since it doesn't seem directly necessary for this effort. ~Brady best -jochen On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
08.10.2012, в 11:23, Brady Eidson beid...@apple.com написал(а): On a slightly different note it seems reasonable to me that a WebCore ResourceRequest have target-type/priority-type information attached to it. I don't know if doing that has come up in the past and different conclusions we reached. I haven't placed a lot of thought into that since it doesn't seem directly necessary for this effort. ResourceRequest is a network level concept, so making it know about whether it loads a stylesheet, a script or an XHR is clearly a layering violation. Giving it some kind of generic priority is not, on the other hand. Anyway, as Brady mentioned, this is not related to this refactoring. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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. Thanks, ~Brady Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
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. Hi Adam, 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. 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
