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.


webkit-dev mailing list

Reply via email to