Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in Thunderbird 3.3a3

Status

Thunderbird
Preferences
--
minor
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: rsx11m, Assigned: rsx11m)

Tracking

({perf})

Trunk
Thunderbird 3.3a3

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
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.
Attachment #507322 - Flags: review?(bienvenu)
(Assignee)

Comment 2

7 years ago
> 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.

Updated

7 years ago
Attachment #507322 - Flags: review?(bienvenu) → review+
(Assignee)

Comment 3

7 years ago
Thanks David, push for trunk please.
Keywords: checkin-needed
Whiteboard: [c-n: comm-central]
Checked in: http://hg.mozilla.org/comm-central/rev/4fd7f9481fc0
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: comm-central]
Target Milestone: --- → Thunderbird 3.3a3
You need to log in before you can comment on or make changes to this bug.