Difference between revisions of "Firefox/Profile on RAM"

From ArchWiki
Jump to navigation Jump to search
m (use mkdir instead of install(1))
m (Relocating only the cache to RAM)
Line 12: Line 12:
==Relocating only the cache to RAM==
==Relocating only the cache to RAM==
{{Note|Rather than doing this, you could just disable the disk cache and increase the size of the firefox memory cache, avoiding needless overhead.}}
<small>''Adapted from [http://bbs.archlinux.org/viewtopic.php?pid=604369 this forum post]''</small>
<small>''Adapted from [http://bbs.archlinux.org/viewtopic.php?pid=604369 this forum post]''</small>

Revision as of 04:14, 3 April 2011

Assuming that there is memory to spare, caching all, or part of Firefox's profile to RAM using tmpfs offers significant advantages. Even though opting for the partial route is an improvement by itself, the latter can make Firefox even more responsive compared to its stock configuration. Benefits include, among others:

  • reduced disk read/writes (ideal for SSD)
  • heightened responsive feel
  • many operations within Firefox, such as quick search and history queries, are nearly instantaneous

Both of previously mentioned options make use of native shared memory; /dev/shm, a directory that behaves just as ordinary mounted file systems do, only with the notable exception that all of its content is stored in RAM.

Because data placed therein cannot survive a shutdown, a script used when moving the whole profile to RAM overcomes this limitation by syncing back to disk prior system shut down, whereas only relocating the cache is a quick, less inclusive solution.

Relocating only the cache to RAM

Note: Rather than doing this, you could just disable the disk cache and increase the size of the firefox memory cache, avoiding needless overhead.

Adapted from this forum post

After entering Template:Codeline into the address bar, create a new string by right-clicking in the bottom half, selecting New, followed by String. Assign its value:


Now, double-click the newly created string and direct it towards the RAM directory:


Finally, create the directory and ensure its permissions have security in mind:

mkdir -m0700 /dev/shm/firefox-cache

Upon restarting Firefox, it will start using Template:Filename as the cache directory. Do mind that the directory and its contents will not be saved after a reboot using this method.

Relocating the entire profile to RAM

Before you start

Before potentially compromising Firefox's profile, be sure to make a backup for quick restoration. Replace Template:Codeline as appropriate and use Template:Codeline to make a backup:

$ tar zcvfp ~/firefox_profile_backup.tar.gz ~/.mozilla/firefox/xyz.default

The script

Adapted from verot.net's Speed up Firefox with tmpfs

The script will first move Firefox's profile to a new static location, make a sub-directory in Template:Filename, softlink to it and later populate it with the contents of the profile. As before, replace the bold sections to suit. The only value that absolutely needs to be altered is, again, Template:Codeline.

Be sure that rsync is installed and save the script to Template:Filename, for example: Template:File

Close Firefox, make the script executable and test it:

$ killall firefox firefox-bin
$ chmod +x ~/bin/firefox-sync
$ ~/bin/firefox-sync

Run Firefox again to gauge the results. The second time the script runs, it will then preserve the RAM profile by copying it back to disk.

From the AUR

The script is available as a package. This version automatically picks the first Template:Codeline directory in your Template:Filename (although that means you should install it with sudo, not as root).

The script also provides a firefox wrapper Template:Codeline, which runs Template:Codeline before and after Template:Codeline. This is an alternative to syncing with cron, or on login/logout (described below). Be careful with the "Restart Firefox" button within firefox, though, since this might not start the wrapper.


Seeing that forgetting to sync the profile can lead to disastrous results, automating the process seems like a logical course of action.

cron job

Manipulate the user's cron table using Template:Codeline:

$ crontab -e

Add a line to start the script every 30 minutes,

*/30 * * * * ~/bin/firefox-sync

or add the following to do so every 2 hours:

0 */2 * * * ~/bin/firefox-sync

Sync at login/logout

Deeming bash is being used, add the script to the login/logout files:

$ echo '~/bin/firefox-sync' | tee -a ~/.bash_logout ~/.bash_login >/dev/null
Note: You may wish to use Template:Filename instead of Template:Filename as bash will only read the first of these if both exist and are readable.