Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Geoffrey Garen]

> 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

[Maciej Stachowiak]

On Oct 10, 2012, at 8:49 AM, Adam Barth  wrote:

> On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak  wrote:
>> On Oct 9, 2012, at 1:50 PM, Adam Barth  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

[Adam Barth]

On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak  wrote:
> On Oct 9, 2012, at 1:50 PM, Adam Barth  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

[Maciej Stachowiak]

On Oct 9, 2012, at 1:50 PM, Adam Barth  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).

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

[Adam Barth]

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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Maciej Stachowiak]

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

[Adam Barth]

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

[Antti Koivisto]

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

[Adam Barth]

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

[Antti Koivisto]

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

[Adam Barth]

On Mon, Oct 8, 2012 at 6:21 PM, Maciej Stachowiak  wrote:
> On Oct 8, 2012, at 5:28 PM, Adam Barth  wrote:
>> On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson  wrote:
>>> On Oct 8, 2012, at 12:17 PM, Adam Barth  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

[Maciej Stachowiak]

On Oct 8, 2012, at 5:28 PM, Adam Barth  wrote:

> On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson  wrote:
>> On Oct 8, 2012, at 12:17 PM, Adam Barth  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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Adam Barth]

On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson  wrote:
> On Oct 8, 2012, at 12:17 PM, Adam Barth  wrote:
>> On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson  wrote:
>>> On Oct 8, 2012, at 11:24 AM, Adam Barth  wrote:
 On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson  wrote:
> On Oct 8, 2012, at 10:58 AM, Adam Barth  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
>> , 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

[Brady Eidson]

On Oct 8, 2012, at 12:17 PM, Adam Barth  wrote:

> On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson  wrote:
>> On Oct 8, 2012, at 11:24 AM, Adam Barth  wrote:
>>> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson  wrote:
 On Oct 8, 2012, at 10:58 AM, Adam Barth  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
> , 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

[Adam Barth]

On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson  wrote:
> On Oct 8, 2012, at 11:24 AM, Adam Barth  wrote:
>> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson  wrote:
>>> On Oct 8, 2012, at 10:58 AM, Adam Barth  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
 , 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

[Brady Eidson]

On Oct 8, 2012, at 11:24 AM, Adam Barth  wrote:

> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson  wrote:
>> On Oct 8, 2012, at 10:58 AM, Adam Barth  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
>>> , 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

[Alexey Proskuryakov]

08.10.2012, в 11:23, Brady Eidson  написал(а):

> 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

[Adam Barth]

On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson  wrote:
> On Oct 8, 2012, at 10:58 AM, Adam Barth  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
>> , 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

[Brady Eidson]

On Oct 8, 2012, at 10:52 AM, Jochen Eisinger  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  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

[Brady Eidson]

On Oct 8, 2012, at 10:58 AM, Adam Barth  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
> , 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  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

[Adam Barth]

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
, 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  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

[Jochen Eisinger]

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  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

[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

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