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.
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.
> 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.
Thanks David, push for trunk please.