Last Comment Bug 629247 - Remove 4MB limit for memory-cache and base it on physical memory size instead
: Remove 4MB limit for memory-cache and base it on physical memory size instead
Status: RESOLVED FIXED
: perf
Product: Thunderbird
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- minor (vote)
: Thunderbird 3.3a3
Assigned To: rsx11m
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-26 17:30 PST by rsx11m
Modified: 2011-02-05 06:34 PST (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Proposed patch (640 bytes, patch)
2011-01-26 17:34 PST, rsx11m
mozilla: review+
Details | Diff | Splinter Review

Description rsx11m 2011-01-26 17:30:28 PST
Historically, the memory-cache size was set to 4MB and disk-cache size to 50MB, changeable by a preference setting. In the networking core, this was changed by bug 309729 to use a formula (updated later by bug 296538) which determines the memory-cache size as a function of the physical RAM available on a machine.

From mozilla/netwerk/cache/nsCacheService.cpp:
>   RAM   Cache
>   ---   -----
>   32 Mb   2 Mb
>   64 Mb   4 Mb
>  128 Mb   6 Mb
>  256 Mb  10 Mb
>  512 Mb  14 Mb
> 1024 Mb  18 Mb
> 2048 Mb  24 Mb
> 4096 Mb  30 Mb
>
> The equation for this is (for cache size C and memory size K (kbytes)):
>  x = log2(K) - 14
>  C = x^2/3 + x + 2/3 + 0.1 (0.1 for rounding)
>  if (C > 32) C = 32

Given that 4MB cache feels ridiculously low these days, adopting this for TB
as well makes sense (especially since many providers have a message-size limit around 30MB now). Ideally, the memory cache should be large enough to keep a full message without having to consult the disk or the network again when revisiting it after a short visit to another message.

I've been using "-1" as default for SeaMonkey without seeing any issues with Mail/News, and have tried both "32768" and "-1" on Thunderbird without any performance issues, however noticing a better performance with large messages when the disk cache is disabled. This will minimally increase the memory footprint, but not beyond other Mozilla applications, and the benefits should justify it.
Comment 1 rsx11m 2011-01-26 17:34:57 PST
Created attachment 507322 [details] [diff] [review]
Proposed patch

The fix for this is straight-forward by removing the all-thunderbird.js override for browser.cache.memory.capacity, thus it will default to the "-1" given in the Core code to use the formula instead of a fixed value (the pref was removed from modules/libpref/src/init/all.js entirely and made hidden,
thus removing it creates parity with Firefox and SeaMonkey in this regard).

This is best tested with mail.server.default.mime_parts_on_demand set to "false" on an IMAP account to allow better control over download sizes, and with the disk cache disabled. Any message smaller than the table limit should load in full, and opening an attachment should get it from memory cache (no network traffic). Visiting a 1k message and going back to the large message shouldn't reload it. In contrast, selecting a message which is larger than the table limit should load it on initial opening, but then again when opening an attachment or after visiting a small message.

Unit tests for cache handling are performed in the Core code.
Comment 2 rsx11m 2011-01-26 18:06:27 PST
> however noticing a better performance with large messages
> when the disk cache is disabled.

This should have read "especially when the disk cache is disabled" as the benefits are obviously also present if the disk cache hasn't to be consulted given that the desired message or message part is in the memory cache.

To see the impact, set browser.cache.memory.enable to "false", in which case
each access has to go through the disk.
Comment 3 rsx11m 2011-02-03 13:47:32 PST
Thanks David, push for trunk please.
Comment 4 Mark Banner (:standard8) 2011-02-04 02:49:53 PST
Checked in: http://hg.mozilla.org/comm-central/rev/4fd7f9481fc0

Note You need to log in before you can comment on or make changes to this bug.