Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Parabéns, Caio! :-) On Mon, Oct 8, 2012 at 10:32 PM, Zoltan Horvath wrote: > > Cool! Congratulations Caio! > > On Mon, Oct 8, 2012 at 2:20 PM, wrote: > >> I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. >> Caio has been working in many areas in the past years, starting with >> focus on the Qt port with improvements to the Qt/JS bridge, font test >> results and render-theme. >> More recently has also work on the UndoManager and other aspects of >> editing code and CSS parsing, his latest contributions being around WTF >> HashMap iterators. >> Since Caio has been involved in so many parts of WebKit, I'm probably >> forgetting a few other contributions... >> >> Please join me in congratulating Caio for his new reviewer status! >> No'am >> ___ >> 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 > > -- --Antonio Gomes ___ 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 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 wrote: > On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak 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 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 wrote: > On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth 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 wrote: > On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto wrote: >> On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth 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 wrote: > On Oct 9, 2012, at 1:24 PM, Adam Barth wrote: >> On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto wrote: >>> On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth 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
