629247 - Remove 4MB limit for memory-cache and base it on physical memory size instead

Status: RESOLVED FIXED

(Thunderbird :: Preferences, defect)

Description

[rsx11m]

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]

Attachment: 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]

> 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]

Thanks David, push for trunk please.

Comment 4

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/4fd7f9481fc0