Recent "improvements" and "regressions" on Talos

[Ehsan Akhgari]

If you've been watching dev.tree-management, you might have noticed a
bunch of improvements and regressions around the time when bug 569709
landed. I have posted my evaluation of these results here:

<https://bugzilla.mozilla.org/show_bug.cgi?id=569709#c37>

Please read that, and feel free to express what you think. I'm going
to hold off on backing anything out unless someone comes up with a
good justification on why we should do that.

--
Ehsan
<http://ehsanakhgari.org/>

[Ehsan Akhgari]

On Mon, Jun 14, 2010 at 9:24 AM, Mike Beltzner <belt...@mozilla.com> wrote:

> On 2010-06-14, at 2:10 AM, Ehsan Akhgari wrote:
>
>> Please read that, and feel free to express what you think.  I'm going
>> to hold off on backing anything out unless someone comes up with a
>> good justification on why we should do that.
>

> Commented in the bug, but worth bringing up to this level as well. I think a memory regression for a larger cache is understood and expected, but how much of one are we willing to take? Can we see an expression of the expected page rendering / user experience performance improvements that come in return?

The cache which we ship as part of Firefox 3.6 can store a maximum of
8192 entries, which means that it takes 128KB of memory (at 16 bytes
per entry) to store the disk cache entry map in memory.

With my patch landed, we have bumped the maximum entry count to
256000, which means that it takes 4000KB of memory to store the disk
cache entry map in memory.

But not all users have to pay that cost starting at today's nightly.
The way that the code works is that when you first start the browser
with an empty cache, only 512 entries are allocated. When you need to
store the 513th entry, we make the available entries buffer two times
bigger, and you will pay more memory cost as your cache grows in
entries.

Speaking of the benefit that this brings to our users, based on a
study which I performed in
<https://bugzilla.mozilla.org/show_bug.cgi?id=569709#c11> (which is
not perfect or representative of any real use case by any means, but
was the best I could come up with), on average a website stores 697KB
of cached items in our disk cache. This means that on Firefox 3.6,
our cache is by default only big enough to store about 73 full
websites, but now it can handle five times that many.

And also, the 8192 maximum entry count limit would mean that in
practice, for many users, we didn't even use out 50MB capacity,
because we could run out of allowed entry counts way before the 50MB
cache would be filled.

--
Ehsan
<http://ehsanakhgari.org/>

[Justin Dolske]

On 6/14/10 8:47 AM, Ehsan Akhgari wrote:

> With my patch landed, we have bumped the maximum entry count to
> 256000, which means that it takes 4000KB of memory to store the disk
> cache entry map in memory.

At first glance, that seems like a lot of overhead to me. It would be
nice to know how that compares to data structures with similar
capabilities (maybe something in JS or jemalloc, but doesn't have to be
in Mozilla).

Justin

[Boris Zbarsky]

On 6/15/10 1:58 PM, Justin Dolske wrote:
>> With my patch landed, we have bumped the maximum entry count to
>> 256000, which means that it takes 4000KB of memory to store the disk
>> cache entry map in memory.
>
> At first glance, that seems like a lot of overhead to me.

Specifically, it's 16 bytes per entry. So 4 words. It's noticeable
overhead, sure, but doesn't seem gigantic, necessarily...

-Boris

[Jonas Sicking]

Also compare keeping 16 bytes in memory, compared to downloading a
network resource from the other side of the world because we purged it
from the cache.

Though we should look at if it makes sense to look at if we can improve
things. Byron Milligan is looking at this and many other cache related
things this summer.

/ Jonas

[Mike Beltzner]

On 2010-06-18, at 3:27 PM, Jonas Sicking wrote:

> Though we should look at if it makes sense to look at if we can improve things. Byron Milligan is looking at this and many other cache related things this summer.

That's awesome! Is there a wiki page holding a list of things into which he is looking?

cheers,
mike

[Jonas Sicking]

It's still very early in this project so we don't even have a plan
beyond "we need to measure!". Once plans formulate I'll make sure they
end up in wiki format.

/ Jonas