Improve Firefox 3 Speeds with tmpfs
Firefox 3 is a significant stride forward in features, but it carries with it an equally significant stride backward in performance. The stats are much better – better memory usage both at startup and over time, faster JavaScript execution, less CPU time – but the browser just felt sluggish, even when it shouldn’t. Thought that your system with a terabyte of RAM and 256 cores could make Firefox soar? It turns out that, for most users, Firefox is actually I/O-bound, in large part because of the switch to SQLite databases.
SQLite is designed to be portable and highly reliable, and it pulls this off with amazing success. However, it does this at the cost of speed. SQLite implements its own journaling system, lock contention procedures, multi-process access, and more. Since SQLite is a portable library, the only way to pull these complex feats off is through standard file I/O. As the volume of data that Firefox stores in SQLite databases grow – and as the number of tabs concurrently trying to access those databases on your system do as well – the time spent by Firefox on secure, hardware-backed I/O grows as well. And since SQLite is so cautious about synchronization, even gobs of RAM and a fast CPU can’t help; the process becomes entirely I/O-bound, particularly at the moments where it should be the most responsive (typing a URL, opening or switching tabs, and the like).
But how attached are you to the last five minutes of your browsing history, really? SQLite’s agonizingly slow access times can destroy performance – and, because of the high volume of writes, it can also destroy sectors on SSDs, USB drives, or other flash media if your profile is on one of these devices. To me, it’s worth accepting a little volatility in the event of a crash for a noticeable and welcome increase in responsiveness.
tmpfs is a virtual, RAM-backed filesystem. It’s lightning-fast, but since it’s RAM-backed, any file written to tmpfs uses precious memory while it’s there, and the entire contents of the virtual partition are lost on shutdown or crash. The good news is that these detriments can be minimized, making tmpfs a viable choice for your profile directory. This document gives some tips on how to mount your Firefox profile in a tmpfs partition while minimizing the downsides of tmpfs.
Step 1. Reduce the size of your profile directory.
tmpfs is RAM-backed, so we want to conserve memory by trimming the fat from the profile. I recommend making the following config changes (enter ‘about:config’ in the Firefox address bar):
set browser.cache.disk.capacity to 20000 or thereabouts
set browser.safebrowsing.enabled to false
set browser.safebrowsing.malware.enabled to false
The first one reduces the size of the disk cache to about 20 MB, down from 50MB. It might be tempting to turn disk cache off entirely, but I’ve encountered poor performance doing that in the past; I think that the caching algorithm has to be able to push things into disk cache for best performance, even if they won’t stay there long.
The last two disable the collection of the information in the ‘urlclassifier*.sqlite’ files. These hold Firefox’s database of suspected malware or phishing sites, and while most users will feel comfortable turning this off, it does in theory leave you more vulnerable to these types of attacks. There’s a known bug in Firefox which can make these files grow quickly; on my system, they were 70MB total.
After you’ve changed these settings, clear the cache in Firefox and delete the urlclassifier*.sqlite files from your profile directory. (SQLite will recreate empty databases but they’ll stay at 32k.) My profile is about 54MB in total size now, which is quite reasonable.
Step 2. Edit the fstab and prepare the backup tarball.
First, create a tarball of your profile as it currently stands.
| Code: |
| $ cd $ cd .mozilla/firefox $ tar cpf packed.tar abcd1234.default |
abcd1234.default should be replaced by your profile directory name here and below.
Now edit /etc/fstab and add a line like this:
| Code: |
| firefox /home/steven/.mozilla/firefox/abcd1234.default tmpfs size=128M,noauto,user,exec,uid=1000,gid=100 0 0 |
You’ll have to adjust path components, uid and gid.
Step 3. Set up a backup and restore script.
This is an example, but is by no means the only way to do it. I’ll assume you’ve named the script “${HOME}/.pack_ffox.sh” in future commands, so replace that with whatever you decide to do.
| Code: |
| #!/bin/bash
# Change this to match your correct profile cd “${HOME}/.mozilla/firefox” if test -z “$(mount | grep -F “${HOME}/.mozilla/firefox/${PROFILE}” )” if test -f “${PROFILE}/.unpacked” |
This script will load your firefox profile if it hasn’t been loaded, and save it otherwise (keeping one backup copy from a few minutes ago in case of file corruption or the like). Once you’ve got it saved, you’ll need to quit Firefox for this next step. Open in links, copy and paste to a text editor, or just remember the steps.
Step 4. Switch over.
With Firefox closed, you need to empty your profile directory. Either move the files currently in there to a new folder, or simply erase them (remember, a copy is in packed.tar as well). Be sure to leave the empty profile directory there for the tmpfs mount point.
Now, run the script:
| Code: |
| $ “${HOME}/.pack_ffox.sh” |
Verify that your profile directory is now mounted on tmpfs, that your files got correctly unpacked, and that the file .unpacked exists inside of your profile directory.
Now run the script again, exactly as before. This time, it will detect that your profile’s been unpacked and is ready to use, and create a new packed.tar. If it worked, you should now have the file “.mozilla/firefox/packed.old.tar” as well.
If both of those things checked out, you’re clear to start Firefox again.
I recommend adding the command to your .xinitrc or desktop-environment-specific startup settings, so that it’s ready to go when you log in. It’s also critical that you run it again before you shut down your computer, or you’ll lose all changes. One of the safest ways for users on media that doesn’t have limited write-cycles is to simply add an entry to the crontab which runs the script every five minutes. Run this command to edit the crontab:
| Code: |
| # crontab -u USERNAME -e |
which will bring up your editor. Add a line akin to this one:
| Code: |
| */5 * * * * $HOME/.pack_ffox.sh |
Check in five minutes to make sure the mtime of packed.tar has changed, indicating that the script is working.








Why would this work faster? Doesn’t Linux cache frequently used files anyway?