[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 <abarth at webkit.org> wrote:

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