With Bug 296538, the calculation of the default capacity of the memory cache will change. Because the calculation of the default bfcache capacity contains a copy of the same code, it seems like it would be idea to make the same change in the other copy of the code at http://lxr.mozilla.org/seamonkey/source/docshell/shistory/src/nsSHistory.cpp#199 With this change, the cap of 8 viewers would be redundant, and the default values for the ContentViewers when browser.sessionhistory.max_total_viewers is -1 would be: RAM current proposed 32 MB 0 0 64 MB 1 1 128 MB 2 1 256 MB 3 2 512 MB 5 3 1024 MB 8 4 2048 MB 8 6 4096 MB 8 7 However, note that due to a rounding error in the current code, the current number of ContentViewers is actually often one less than shown in the table.

I think that you're throwing the baby out with the bath water. In an effort of following the same algorithm as bug 296538, you're dividing the number of content viewers by 2 (for people with 512 MB of RAM) ! Why ?

(In reply to comment #1) > I think that you're throwing the baby out with the bath water. In an effort of > following the same algorithm as bug 296538, you're dividing the number of > content viewers by 2 (for people with 512 MB of RAM) ! Why ? First of all, most, if not all, computers with 512 MB of RAM are actually using only 4 ContentViewers due the rounding error in the current code. This change will reduce that number to 3, a reduction of a mere 25%. Second, the reason for doing this is that the intention of the code is that the bfcache use on average about as much memory as the memory cache. Without this change, the bfcache may be using significantly more memory on average, for example on computers with 1024 MB of RAM bfcache will be using nearly twice as much memory on average for the bfcache, diluting the benefits of Bug 296538. Third, there are many Firefox users complaining about the high memory usage of Firefox. The change to the memory cache values in Bug 296538 is to trim the memory usage, and we can get a similar reduction in memory usage with this change to the bfcache. By comparison, nearly no one is complaining that the bfcache isn't fast enough or doesn't cache enough pages, suggesting that the current default errs to the side of using too much memory.

This is low-hanging fruit for reducing Firefox's memory usage. Why not get this in for Firefox 3 if there's so much other effort being done according to <http://www.squarefree.com/2007/09/20/firefox-memory-usage-and-memory-leak-news/>?

roc's approach for timing things out of bfcache might be better, fwiw. We could do both of course, but is it worth it?

-'ing this, but putting as wanted1.9. I don't see blocking the release for this, and we need to see the result's of the bfcache timing mechanism by roc. Also, we'd definitely take a patch for this. Just request approval once completed.

Comment on attachment 427326 [details] [diff] [review] patch to reduce bfcache cache size clearly, I'm not getting to this review.