Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read a DownloadSquad article, Speed up Firefox page loading time without using a RAM disk, that recommended an option for Mozilla Firefox that moves the cache to RAM. I could see why it would speed things up; why isn't it on by default then?

Is there a downside?

share|improve this question
up vote 2 down vote accepted

Two reasons I would guess why it's not on by default:

  • People already complain about how much memory Firefox uses.
  • Each process has a maximum amount of memory it can (readily) allocate. Using some of that for a cache makes it more likely to hit that limit, which might cause the process to crash. (Only really an issue for 32-bit, but that's still probably most people.)

These are exacerbated when Firefox "leaks memory", as it apparently can (which leads to the first issue).

As long as Firefox "fits in memory" by itself, I don't see much of a downside. The OS manages how much of each process's memory is in RAM, and when necessary, pages to disk. So worst case, your Firefox cache goes to disk. If you allocate too little for the memory cache, you might see performance suffer, since it will be forced to fetch over the network, which is slower than disk.

Interaction with other processes and what gets paged when is hard to generalize in a "rule of thumb" way. So if you're using other programs along with Firefox, which is now definitely using more memory, you might see some effects there.

But go ahead and try it.

share|improve this answer

Partial downside is that it will eat up more RAM, depending on how many tabs you have open...Also, if you have a lot of tabs open, and many programs running, Firefox will likely slow the opening/refreshing of webpages...

same article at

share|improve this answer

This can't be the default because you can't assume that every user is going to have tons of RAM and a 64-bit OS. Also, you eventually want to sync up cache to disk, so that you don't lose your entire cache when you shut down Firefox or your computer.

I think a better approach is to leave the cache on the filesystem, but to use a smarter filesystem driver that can receive hints about files that have low priority to be synced to disk, so that many changes can be accrued in memory over a long period of time without the changes being committed to physical media. This would provide performance comparable to a RAM disk without having to modify the application at all.

If you're on Windows, you might be kinda stuck unless you use a third party filesystem driver (or try ReFS in Windows Server 8; not sure if it does delayed commits). If you're on Linux, you can try certain features of ext4 such as delayed commits and delayed allocation; you can also disable the safety feature that prevents files from being committed to disk until fsync() is called on them. This reduces data safety in the general case, but for a cache, you really don't care if you lose the data due to a random power failure, right? It's not valuable data, and you're more interested in performance than data integrity. If the cache is corrupted then FF can just delete it and start over.

As for my original idea of a filesystem that can take a "hint" that certain files are not valuable and don't need to be committed unless there's memory pressure to push the pages out from memory: that would be nice but I don't know if any active FSes on any platform do that. Sounds like something that needs to be added to the POSIX standards. Most filesystems today violate the standards by automatically syncing data to disk every N seconds (usually 5 - 15 seconds) even if the program doesn't call fsync(), so now we need a way to tell it, "whoa whoa wait a minute, I really don't care about these files and would rather you NOT sync them unless the system is shutting down". Filesystem design detail though... not sure if you're into that kinda stuff :)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.