User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 If I have Mozilla's browser cache set to 10240KB, Mozilla tends to stick to it quite well (give or take a meg). If I set it to 15360KB, it doesn't seem to mind growing to 18MB or 26MB. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Are you referring to the disk cache or memory cache? Only the disk cache has UI in the pref dialog to change it, but both caches have prefs in prefs.js that can be set.
can you look in about:config, find the pref value mentioned in the new summary, and put that value here?
In the prefs GUI I had set the cache back to 10MB, the value in about:config is what I set it to in the prefs GUI, 10240. I'll set it to 15360KB again now and do some web browsing :) (It's been on 10MB for about 5 days now, cache dir size is 10.9MB, is staying around that size)
Just updated to 1.4b release version, and vaped my profile for a new one (with as little importing as possible, bookmarks, address book and mail only) as I think some problems I was experiencing with mozilla were as a result of profile oddness. I've set my cache size to 15MB and I'll see how things go with that.
Currently at 16.5MB. I'll try to keep an eye on it over the next few days.
18MB, just dipped down to 17.8MB.
Confirming again with 1.5 release. 15MB cache set, cache folder is currently 17.8MB in size. Maybe this should change into an RFE to suggest adding a help or extra bit of preferences text to say that the limit is not strictly adhered to, that the cache may go over give or take a few megs?
mike: if after the cache bloats up above 15 MB, you close all browser windows except one, and load about:cache into that browser window, does the cache limit still show an amount above 15 MB?
No, it thinks the amount in use is below the quota, which it currently isn't. The contents of the dir is being reported by Windows (2000) as: Size: 18.1 MB (19,008,735 bytes) Size on disk: 18.4 MB (19,374,080 bytes) Contains: 189 files, 0 folders This is what about:cache is reporting: Disk cache device Number of entries: 2088 Maximum storage size: 15360 k Storage in use: 15213 k Cache Directory: D:\mydocs\Mozilla\mike\8y0lc6f8.slt\Cache The cache dir is correct.
"The cache dir is correct" I mean, the location of it reported by Moz is the same as what I'm checking, there's no discrepancy there.
ah... ok... hmm... and you say this is the case when you have only one browser window open? i'm asking because we do intentionally allow the cache to "bloat" a bit during page load. oh... but, i bet the real explanation for what you are seeing is the fragmentation of the cache. you see, because of the way the cache is structured, there are iheritently holes in the block files (the files named _CACHE_001_ etc.). these holes add up, and end up making the physical size of the cache larger than the sum of all the useful data stored in the cache. the cache size as reported on about:cache is measuring the sum total of all useful data in the cache. i hope this clears things up, and i agree that this might be a good thing to add to the release notes. benc, timeless: can either of you please update the release notes with this one? thanks!! marking WONTFIX. mozilla is behaving as designed.
Is it worth blowing away the cache from time to time? Is this issue [cache fragmentation] likely to cause a performance hit?
no, the cache is designed to avoid a performance hit. the problem is not cache files being split up into segments... in fact, we always store files in single continguous blobs. the issue is that the size of those blobs are rounded up to the nearest multiple of 256, 1024, or 4096 bytes. that can leave quite a few bytes unused. for example, a 9000 byte file would require three 4k blocks. the result is 3*4096 - 9000 = 3288 unused bytes. this adds up, but i don't think it has a significant affect on overall performance. _CACHE_001_ contains 256 byte blocks _CACHE_002_ contains 1024 byte blocks _CACHE_003_ contains 4096 byte blocks data larger than 16k is stored as an individual file. we fill the block files from the front.
we talked this over on irc. i'm not going to relnote it because the relnote would be worse than the ones i've been tempted to write for things like quicklaunch (and that was really scathing). mike: i'll make you an offer, if you're interested in fixing the cache to honor the pref in the way you expect and willing to spend a month or two on it then contact me on irc, i'll help. personally i'd VERIFY INVALID since we do honor the pref, it's just that our interpretation doesn't match what any user expects. I will consider checking in an html help change (no review) after alpha releases which says the following (or something like it): The disk cache capacity setting controls how much data mozilla holds in the disk cache, not how much space it will take on disk.
No programming experience here. I'm just an ignorant sysadmin :-)