531485 - Specified Cache values not used; FF uses bad bad values

Status: RESOLVED WORKSFORME

(Firefox :: Settings UI, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-UTF-8; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-UTF-8; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

I Specifically and continually set Firefox to NOT use disk space -- not use a disk cache, or use 5-128k -- tried various values.  It keeps resetting it to 150Mb and cache on.  I told it to use (instead) 1.5GB of memory for cache.  After running for
some time, I checked on the cache usage.  It had again reset the disk cache to 150MB, and had used 147MB of disk cache -- AND!@!!!  it had only used 12 bytes in 8 items in the memory cache!!!!

WTF!!!...Talk about spite that bites!  IT's not only doing the opposite of what I want, but in multiple-power-of 2 multipliers!

It used 147MB in disk and 12 bytes of memory cache!?! when I tell it it has 1.5GB of RAM and to NOT use disk (or use only 128K)?    Geeze...like it's being deliberately obstreperous! :-)

Ok, someone is making some bad assumptions about how we want the browser to use cache.  Like to minimize memory, and only put small things there, and to always use a disk cache whether the user wants it or not -- and to use multiple megabytes?  I have 15GB of RAM, I'm not going to miss 1.5G to my browswer.  I know FF is limited to 2GB or so being a puddly 32-bit prog, but I figured I'd tell it that it could use as much RAM as it can deal with for cache -- and it it ignores it.

This is pretty bad and explains why my disk is thrashing while FF goes out to lunch for long periods.  It's thrashing it's cache on disk -- when it could be
going to memory MUCH faster.

This is very  very bad.  What's the point of claiming FF enables us to take our desktop back when it doesn't listen to such basic config params?

(While your at it, making FF large mem aware, could allow it to use up to 3GB even in 32 bit mode -- though a 64 bit version on win and linux for that  matter, would be nice (multithreaded, of course).

Hey, the 64-bit part should be a recompile -- and ignoring users specified params -- literally resetting them! -- that's a severe, critical bug. IMO.



Reproducible: Always

Steps to Reproduce:
1. set disk usage to 0 in UI
2. use about:config to set mem cache usage high -- turn disk caching off even,
3. restart...
Actual Results:  
see disk usage go back up to ~150MB, and turn back on...
mem cache value stays untouched, but run for a while...
see that firefox *wrongly* prefers disk cache over mem-cache, even when mem cache is larger.

Expected Results:  
1) exepct ff to use user values.
2) expect ff to use fastest cache first, proportional to the relative sizes of the caches.  i.e. if mem cache was 1mb and disk was 150mb, I'd expect items larger than ~1/20th the size of the mem cache to go to the disk cache.  But if
mem cache is 1.5GB and disk cache is 15k, I'd expect anything and everything to go to the mem cache as it is faster.  Disk cache should only be used when mem cache is smaller.
UNLESS, it is of large size AND user doesn't have "clear cache at shut down" turned on", and the disk cache might be re-used.  Otherwise, the disk cache is worthlessly slow.

Comment 1

[L A Walsh]

(sorry for re-edits -- keep remembering bug parts I forgot)

BTW -- NOTE

The disk cache reset isn't specific to Win7 or 64bit, happens on my
WinXP-32 box as well.  Not sure about the mem cache vs. disk cache usage
there, specifically, I try to set it to ~ 515MB, (only have 3G on XP), which
is still alot more than I'd want it to use in *slow disk* cache.

Besides -- I already have a disk cache!  I run squid on a separate machine
over a gigabit ethernet.  It's got it's own set of raid disks to run on, so
it's always of 'reasonable' speed and holds GIGAbytes of cache.  That's
why I don't want my FF clients running local disk caches.  It wastes disk
space and my time).  Random read/writes to a linux-server with ~24GB of memory make for most squid-cache requests to be held in memory...then we're talking just network transfer speed or about ~100MB/s -- alot faster than random access R/W to my local disks.

I know it's not every users config, BUT, that's supposed to be why FF is configurable.  If it ignores the config values (or worse, resets them), that's bad.

-l

Comment 2

[L A Walsh]

FYI -- More info -- the 'reset' of the disk cache values seem to happen immediately after a fresh boot of ff.  Testing:

Before reboot, noticed values were as I set.
After 'close' checked the prefs.js file and values were still as I set.

After starting browser, values were reset to the bad defaults.

So I reset them at run time (set it to zero in the tools-options.

After running for sometime, I now have all of 1.5M of memory cache used, and NO disk cache allocated.

So it seems to be some sort of initialization bug -- though the fact that it preferred the disk cache of 150MB (that's cleared on FF exit (or is *set to be...who kows if that is working!*) over the 1.5GB of MEMORY available, is still a runtime issue.

Comment 3

[Wayne Mery (:wsmwk)]

Tyler, is this a dup of the bug I touched yesterday?  I don't have a good sense of which *single* issue this bug is about - summary is non-specific.

Comment 4

[Tyler Downer [He/Him]]

Wayne, do you mean bug 433969? Possibly could be.
Reporter, can you please rear bug 433969 and let us know if it is similar to the issue you are describing? If it isnt, please provide a clear and concise summary of the problem.

Comment 5

[L A Walsh]

Hmmm....

This bug appears to no longer be present in 3.6.13 (running on win7-64bit)

i.e. my disk cache is set for 0 (stays 0), and pictures are now being stored in memory.

'Test':
I loaded a few pages from 'animepaper.net', and largest, picture stored in memory was a 4.5MB png file with a 24 hour expiration!  18.7Mb total.

Thanks!


BTW, is the large-image flag (or whatever the Win-flag is called) set on FF yet so it will use up to the full 4GB in the 32-bit version (of course better yet, would be a 64-bit version -- would definitely give me reason to upgrade my mem from 24G-> 48G!  ;-)  (memory is VERY cheap right now -- bottom fell out of market after slow Holiday sales).