# [TIP] Firefox and tmpfs: a surprising improvement

## stevenrobertson

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.

```
$ 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:

```
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.

```
#!/bin/bash

# Change this to match your correct profile

PROFILE="abcd1234.default"

cd "${HOME}/.mozilla/firefox"

if test -z "$(mount | grep -F "${HOME}/.mozilla/firefox/${PROFILE}" )"

then

    mount "${HOME}/.mozilla/firefox/${PROFILE}"

fi

if test -f "${PROFILE}/.unpacked"

then

    tar --exclude '.unpacked' -cpf packed.tmp.tar "$PROFILE"

    mv packed.tar packed.tar.old

    mv packed.tmp.tar packed.tar

else

    tar xpf packed.tar &&\

    touch "${PROFILE}/.unpacked"

fi

```

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:

```
$ "${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:

```
# crontab -u USERNAME -e
```

which will bring up your editor.  Add a line akin to this one:

```
*/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.

I hope this works as well for you as it did for me!

Changes:

2008-12-07 Added 'exec' to mount opts.

2008-12-05 Rewrote the guide based on feedback and a sore need for some editing.Last edited by stevenrobertson on Sun Dec 07, 2008 10:00 pm; edited 4 times in total

----------

## SlashBeast

Work for me, thx.

My fstab entry:

```
firefox      /home/slashbeast/.mozilla/firefox/asdfg123.default   tmpfs   size=64M,noauto,user,uid=1000,gid=100 0 0
```

noauto,user for mount after I login (encrypted /home.  :Smile:  ), size for limit space, uid and gid for owner rights.

script:

```
slashbeast@mizore .mozilla % cat ff-tmpfs.sh

#!/bin/sh

PROFILE="asdfg123.default"

cd "${HOME}/.mozilla/firefox"

if test ! -f "${PROFILE}/.unpacked"

then

   mount ${PROFILE} && \

   tar xpf packed.tar && \

   touch "${PROFILE}/.unpacked"

else

    tar cpf packed.tmp.tar "$PROFILE" && \

    test -f packed.tar && mv packed.tar packed.old.tar && \

    mv packed.tmp.tar packed.tar

fi

```

----------

## Cazzantonio

Isn't just enough to set browser.cache.disk.parent_directory=/dev/shm to cache files in tmpfs?

----------

## M

I think it is not enough, I just tried this and now firefox feels a lot smoother, there are also .sqlite databases for places, search, form history etc in profile. The new url bar was always lagging for me, I had to wait a few seconds before the results for complete appear, now it's really smooth. You will actually loose your cache files this way when you reboot.

----------

## zyko

Unfortunately, firefox needs the disk after all. This seems to be an inherent design feature. I have put quite a lot of investigation into this issue and could still not eliminate disk access completely.

Here are some more thints:

Mount or symlink all of these into RAM (tmpfs):

 /tmp

 /var/run

 /var/lock

 /var/log (be careful, you will lose all logs when rebooting!)

 /var/tmp

 /usr/tmp

 ~/.adobe (flash junk)

 ~/.mozilla (duh)

 ~/.macromedia (again flash -- flash saves a lot of junk)

 ~/.thumbnails (probably not necessary for ff, but cruft piles up in there)

You only need to backup ~/.mozilla (or only parts of ~/.mozilla) and maybe /var/log. All other directories listed above are meant for temporary data anyway.

The following options (about:config) refer to places in ~, /usr or /etc and can cause disk access: 

 java.default_java_location_others

 java.default_java_location_solaris

 java.global_java_version_file

 helpers.global_mime_types_file

 helpers.global_mailcap_file

 helpers.private_mailcap_file

 helpers.private_mime_types_file

Depending on your needs, you may want to just leave those blank. The default settings may be wrong anyway (non-existing files/dirs).

I personally like to use sys-apps/preload to shuffle as much data as possible into memory. It prolongs the boot sequence, but afterwards it decreases the frequency of hdd reads.

If you know more, please post here  :Smile: 

Firefox still makes my disk spin up randomly. It happens mostly when opening/closing tabs or following a link, but not always and not in a predictable pattern.

----------

## Cazzantonio

It isn't that simple to mount on tmpfs /var/{lock,log,run} since some files (es. /var/run/utmp) and subdirectory structure must be preserved.

I wrote a simple initscript that must be added to boot runlevel to safely mount those directories in ram.

Remember to restart the script when you do some emerge since subdirectories added by portage must have a backup to be recreated at boot.

 *Quote:*   

> #!/sbin/runscript
> 
> depend() {
> 
>         after localmount root
> ...

 

----------

## niick

Firefox starts so fast now! woot!

Thanks for the tip steven  :Smile: 

----------

## zyko

 *Quote:*   

> It isn't that simple to mount on tmpfs /var/{lock,log,run} since some files (es. /var/run/utmp) and subdirectory structure must be preserved.

 

As far as I can see, utmp is emptied on system boot by the bootmisc runscript. Bootmisc depends on localmount, so /var/run should be set up and ready to go when bootmisc starts, as long as it is listed in fstab.

/edit: This holds true for baselayout-2/openrc.

----------

## kg4ysy

I tried this trick and only one thing didn't work.  The ebay companion toolbar stops working when I mount firefox in tmpfs.  It says something about missing binaries.  I tried reinstalling the companion and get the same problem.  I don't really understand it, but I'll keep trying.  Anyone have any ideas?

----------

## stevenrobertson

 *kg4ysy wrote:*   

> It says something about missing binaries.

 

In fstab, 'user' implies 'noexec'. Add 'exec' to your mount flags for the tmpfs partiton.

----------

## kg4ysy

 *stevenrobertson wrote:*   

>  *kg4ysy wrote:*   It says something about missing binaries. 
> 
> In fstab, 'user' implies 'noexec'. Add 'exec' to your mount flags for the tmpfs partiton.

 

You rock!  That fixed it.  This was a deal breaker if it didn't work.

----------

## Dont Panic

Thanks for the tip.  This has speed up Firefox considerably.

Now I just need to find a good place to put the script so that it's executed as soon as I log in.  I use kdm or gdm, so I skip .xinitrc.  I also play with several WM/Desktop Environments, and I'm trying to think of the best place to trigger the script regardless of which WM/DE I start.

----------

## kg4ysy

 *Dont Panic wrote:*   

> Thanks for the tip.  This has speed up Firefox considerably.
> 
> Now I just need to find a good place to put the script so that it's executed as soon as I log in.  I use kdm or gdm, so I skip .xinitrc.  I also play with several WM/Desktop Environments, and I'm trying to think of the best place to trigger the script regardless of which WM/DE I start.

 

Since I am for the most part the only user, I just created a file in /etc/init.d to run the script on boot.  It seems to work alright.

----------

## Dont Panic

I did some digging to find some good places to place a hook to run the "${HOME}/.pack_ffox.sh" script as the user on login.

If you are using xdm/gdm/kdm, a good place would be ${HOME}/.xprofile.  I don't think this file exists by default in Gentoo, so you'd need to create the file.  But it just needs permissions similar to the .bashrc file.

However, I discovered that if you use 'startx' from a console to get your X session going, the .xprofile file is NOT used.  So if that is your practice, you'll be better off modifying your .xinitrc file.

----------

## Sadako

 *Cazzantonio wrote:*   

> It isn't that simple to mount on tmpfs /var/{lock,log,run} since some files (es. /var/run/utmp) and subdirectory structure must be preserved.

 This is very true, but I found it a lot easier to just add most of the changes I wanted/needed directly to the bootmisc init script, which will be protected by config-protect, and I was trimming a load of stuff from it anyways.

wrt to /var/run/, typically all you have to restore there are directories for daemons which don't run under root, so I found it easier to just add a chack for that directory and create it if not found to each daemon's init script.

`equery b /var/run` should give you a list of everything added to that dir via portage, and here's what I added to the mpd init script for example;

```
        RUNDIR="/var/run/mpd"

        if [ ! -e "${RUNDIR}" ]; then

                mkdir -m 750 "${RUNDIR}"

                chown mpd:audio "${RUNDIR}"

        fi
```

----------

## brfsa

I did it in OSX leopard..

and it's F***ing fast now!!!

Awesome!

Start Script:

```

#!/bin/bash

cd ~/Library/Cache/Firefox/

VolumeName="Mozilla"

SizeInMB=220

NumSectors=$((2*1024*SizeInMB))

DeviceName=`hdid -nomount ram://$NumSectors`

echo $DeviceName

diskutil eraseVolume HFS+ RAMDisk $DeviceName

mv Profiles Profiles_ &&

ln -s /Volumes/RAMDisk ./Profiles &&

# gcp is from coreutils from macports

/opt/local/bin/gcp -a Profiles_/* Profiles

```

Stop Script:

```

#!/bin/bash

cd ~/Library/Cache/Firefox/

#again, rsync from macports

/opt/local/bin/rsync -av --delete ./Profiles_/ ./Profile/

umount /Volumes/RAMDisk

rm Profiles

mv Profiles_ Profiles

```

Thanks a lot for this great idea...

----------

## brfsa

why dont you guys use Rsync instead of Tar? 

it's much faster...

also, when using tmpfs, if you do not specify the size, it will grow automatically. 

which is better, isn't it?Last edited by brfsa on Wed Dec 17, 2008 9:43 pm; edited 1 time in total

----------

## stevenrobertson

 *brfsa wrote:*   

> why dont you guys use Rsync instead of Tar? 
> 
> it's much faster...

 

On my machine, it's not - one contiguous write is quicker than many read/write cycles. YMMV, of course.

Thanks for contributing the OS X script! A friend was looking for a way to get it to work there too.

----------

## brfsa

 *stevenrobertson wrote:*   

>  *brfsa wrote:*   why dont you guys use Rsync instead of Tar? 
> 
> it's much faster... 
> 
> On my machine, it's not - one contiguous write is quicker than many read/write cycles. YMMV, of course.
> ...

 

you welcome...  :Wink: 

I see why, I have actually 5 profiles, altogether about 180MB, so rsync is much faster than to tar up the whole thing...

if you have just 1 profile, which is like 30-40mb, tar might be better option.

Im not sure if adding "--size-only " to rsync options will be faster....

----------

## brfsa

 *stevenrobertson wrote:*   

> 
> 
> On my machine, it's not - one contiguous write is quicker than many read/write cycles. YMMV, of course.
> 
> Thanks for contributing the OS X script! A friend was looking for a way to get it to work there too.

 

I just realized that actually tar is faster because you are reading from memory  :Smile: 

not from the hd.

that's cool

I will update my script.

----------

## hoacker

HELL! This is incredible! Firefox used to be very unresponsive during "updatedeb" or "emerge --sync". All gone with tmpfs. A brand new experience! 

Thanks for the tip!

----------

## justinkb

couldn't you just symlink the *.sqlite files to a folder outside the tmpfs partition instead of disable the safebrowsing entirely?

----------

## devsk

So, not only I need 350MB to run the damn browser but now I also need another 128MB to speed it up? great!

But I got 4GB....  :Razz:  so who cares...  :Wink: 

----------

## avx

Nice idea, am modifying it for Opera.

One question though, what about squashing the profile, putting aufs/unionfs/... on top and bring all this in RAM, would that be beneficial? There are threads around to do it with portage, so it shouldn't be a problem to adopt it, just a mather of it making sense for this task or not.

input, input  :Smile: 

Edit:

Time the creation of a tarball (tar -pcf ...) and a squashfs (mksquashfs ... -no-duplicates -no-progress) of my ~21mb .opera.

time: 

```
tar: 0,03s user 0,14s system 3% cpu 5,298 total

mksquashfs 6,20s user 0,28s system 98% cpu 6,553 total
```

This is from an 1.2GHz Pentium M & 4.2krpm disk.

Achieved filesize is 19mb(tar) vs. 6.7mb(mksquashfs)

----------

## dirk_salewski

 *brfsa wrote:*   

> also, when using tmpfs, if you do not specify the size, it will grow automatically. 
> 
> which is better, isn't it?

 

Specifying the size of a tmpfs puts a growth limit on it which is different to the default tmpfs growth limit you specified in your kernel config. But it will still grow and shrink automatically.

----------

## stevenrobertson

 *ph030 wrote:*   

> Nice idea, am modifying it for Opera.
> 
> One question though, what about squashing the profile, putting aufs/unionfs/... on top and bring all this in RAM, would that be beneficial? There are threads around to do it with portage, so it shouldn't be a problem to adopt it, just a mather of it making sense for this task or not.

 

It would work, but it wouldn't buy you much.  IIRC aufs/unionfs/etc. do full-file copy-on-write, rather than differential storage, so the net effect would end up being almost identical in terms of RAM usage and speed boost (because stuff would get quickly copied to RAM as firefox writes to nearly everything in its profile directory).

----------

## Ormaaj

Putting /var on it's own partition might help. I use Polipo as a cache.Last edited by Ormaaj on Thu May 17, 2012 2:57 am; edited 1 time in total

----------

## xmaes

thank you very much for the tips.

Went from nothing to firefox in tmpfs + polipo (cache in tmpfs) + privoxy + swichproxy ( from time to time i have problem downloading files from gmail when the proxy is enable).

i added .pack_ffox.sh to my .bash_profile and .bash_logout.

I added polipo -c /home/xavier/.polipo to my gnome session to setup polipo cache in my firefox profile because setting it the /etc/polipo/config file didnt work when running polipo wirth 'rc-update add'

I disable firefox's cache

i am not using gdm

I am not too sure if it is the best way to do it, i am still learning and experiencing...

it is fast and i am not getting those stupids adds anymore.

Xavier

----------

## Enlight

I'm sorry to ask, but I tried to mount my .mozilla on tmpfs and got _no_ mesurable improvement.

Did you guys who tried this after having FF to run did a echo 3 > /proc/sys/vm/drop_caches before running firefox again? Or did anybody saw  and improvement on first launch?

----------

## stevenrobertson

 *Enlight wrote:*   

> I'm sorry to ask, but I tried to mount my .mozilla on tmpfs and got _no_ mesurable improvement.
> 
> Did you guys who tried this after having FF to run did a echo 3 > /proc/sys/vm/drop_caches before running firefox again? Or did anybody saw  and improvement on first launch?

 

I'm on an SSD currently, so this hack makes little measurable difference in startup speed.  However, it continues to make a tremendous difference for anything that hits the databases - using the awesomebar (location bar), opening a tab, clicking on a link, etc. These activities are mostly write-bound, with the exception of reading autocomplete data, so the pagecache doesn't really matter.

----------

## Enlight

Wow I just trid to solve the problem statisticaly...

I ran strace -e open -o $file firefox, then put $file through a perl script to get my fields in dirname, basename, filedescriptor format.

I then submited that to oocalc datapilot asking him to count file accessed in each directory and splitting answers in fd < 0 or fd <= 0 cases.

Here are the results : at the time Firefox asks me wether i want my last session back or not, it has already opened 727 files! This number grows up to 1081 at the moment my pages are shown. Out of this 1081 files, 414 do not exists and out of this 414, 126 are in /usr/lib64/mozilla-firefox... WTF???!!!

still i have continued  and came to that conclusion :

/usr/lib64/xulrunner-1.9 holds 252 files accessed at start time and weights 27Mb

/usr/lib64/mozilla-firefox holds 222 files accessed at start time and weights 4Mb

~/.mozilla/firefox/$blah.default holds 92 files accessed at start time and weights 72Mb

using tmpfs on theese 3 dirs would mean having 100Mb of ram holding 566 out of the 1081 files opened by FF at runtime (I.e. 52%)

so I did it, screwed the filecache with echo 3 > /proc/sys/vm/drop_caches and ran firefox

and it was... still slow as hell to launch  :Sad: 

edit : seems the ENOENT problem in /usr/lib64/mozilla-firefox is related to the gnome  support while not running gnome.

edit 2 : down to 820 files without gnome support.Last edited by Enlight on Thu Jan 15, 2009 11:56 pm; edited 1 time in total

----------

## SlashBeast

Enlight, you know how to do all of the cool stuff (how using strace etc.  :Razz: ) so I have idea, can you find out why binary firefox from mozilla is lighter and imho faster than compiled from source?

----------

## Sadako

 *SlashBeast wrote:*   

> Enlight, you know how to do all of the cool stuff (how using strace etc. ) so I have idea, can you find out why binary firefox from mozilla is lighter and imho faster than compiled from source?

 Building www-client/mozilla-firefox with both custom-optimization and xulrunner USE flags disabled should actually result in a "faster", or at least more optimized firefox build, and one more similar to their binary builds too, so try that first.

----------

## Palatis

I made a script to do it on a per-user basis, no need to touch "/etc/fstab".

it untars the tarball to an already-mounted tmpfs partition, in my case the "/tmp".

if your "/tmp" doesn't mount in tmpfs, you can always try the /dev/shm which is a glibc requirement.

WARNING: you have to manually tar the ~/.mozilla/firefox.tar file for the first time, or you destroy ALL your existing firefox profiles.

this can be done with

```
$ cd ~/.mozilla/

$ tar cf firefox.tar firefox
```

and here is the script...

```
#!/bin/bash

# change this if your /tmp is not a tmpfs.

TMPDIR="/tmp/.private/${USER}"

TMPARCHIVE="${TMPDIR}/firefox"

MOZDIR="${HOME}/.mozilla"

FXARCHIVE="${MOZDIR}/firefox.tar"

# initialize

if [ ! -d "${TMPARCHIVE}" ]

then

   mkdir -p "${TMPDIR}"

   tar xf "${FXARCHIVE}" -C "${TMPDIR}"

   ln -sfn "${TMPARCHIVE}" "${MOZDIR}/firefox"

fi

# run firefox

firefox

# finish up

if [ -e "${FXARCHIVE}" ]

then

   rm "${FXARCHIVE}"

fi

cd "${TMPDIR}"

tar -cf "${FXARCHIVE}" firefox
```

----------

## teapot

 *Hopeless wrote:*   

>  *SlashBeast wrote:*   Enlight, you know how to do all of the cool stuff (how using strace etc. ) so I have idea, can you find out why binary firefox from mozilla is lighter and imho faster than compiled from source? Building www-client/mozilla-firefox with both custom-optimization and xulrunner USE flags disabled should actually result in a "faster", or at least more optimized firefox build, and one more similar to their binary builds too, so try that first.

 

Firefox and Openoffice can benefit a lot from using the -Os (optimize for size) compiler flag. 

I moved the firefox user directory to RAM , following the instructions in this excellent guide!. I also recompiled firefox with the -Os flag. As long as I don't have an insane number of tabs , Firefox runs really smooth. 

The performance glitches used to bug me , bot not anymore.

I don't know which flags the official builds use , but at least if you are using O3 you should notice quite a difference.

Some Gentoo users seem to believe that O3 is the way to go for a fast desktop.

I still have a growing anger within me over the sad fact that applications become more and more bloated with time though.

Firefox is an awesome browser by many means , but I do not believe that it is really necessary to access 800 (or what was it?) files during startup.

----------

## Sadako

 *teapot wrote:*   

>  *Hopeless wrote:*    *SlashBeast wrote:*   Enlight, you know how to do all of the cool stuff (how using strace etc. ) so I have idea, can you find out why binary firefox from mozilla is lighter and imho faster than compiled from source? Building www-client/mozilla-firefox with both custom-optimization and xulrunner USE flags disabled should actually result in a "faster", or at least more optimized firefox build, and one more similar to their binary builds too, so try that first. 
> 
> Firefox and Openoffice can benefit a lot from using the -Os (optimize for size) compiler flag. 
> 
> I moved the firefox user directory to RAM , following the instructions in this excellent guide!. I also recompiled firefox with the -Os flag. As long as I don't have an insane number of tabs , Firefox runs really smooth. 
> ...

 Without "custom-optimization", the majority of firefox is actually compiled with -Os, and then other select parts/components are compiled with -O2.

I have pretty much everything compiled with -O2, but I'm starting to compile more and more with -Os via /etc/portage/env/.

When I started out with gentoo, I went with -O3 globally 'cause I didn't know any better, and tbh I'm surprised it didn't put me off gentoo altogether...

 *Quote:*   

> I still have a growing anger within me over the sad fact that applications become more and more bloated with time though.

 Same here, kinda makes me want to fetch a load of ebuilds from 2004 and see how well they still work...

----------

## Ormaaj

 *Hopeless wrote:*   

> I have pretty much everything compiled with -O2, but I'm starting to compile more and more with -Os via /etc/portage/env/.

 Sorry for the O/T, but can you please explain or point me to some documentation on how to use / what format those files need to be in? All I could find about /usr/portage/env was a few vague forum references to it in a few blogs via google. IIRC man 5 portage doesn't even have that directory listed as having a function.

----------

## Sadako

 *Ormaaj wrote:*   

>  *Hopeless wrote:*   I have pretty much everything compiled with -O2, but I'm starting to compile more and more with -Os via /etc/portage/env/. Sorry for the O/T, but can you please explain or point me to some documentation on how to use / what format those files need to be in? All I could find about /usr/portage/env was a few vague forum references to it in a few blogs via google. IIRC man 5 portage doesn't even have that directory listed as having a function.

 Sure, tbh I can't even remember how/where I learned about it, but I know full well about the lack of documentation for this feature.

Take (for example) media-video/ffmpeg, if you have CFLAGS="-O2 -march=k8" in make.conf, but wish to have ffmpeg compiled with -O3, you'd create the file (and parent directories) '/etc/portage/env/media-video/ffmpeg', and simply add 'CFLAGS="-O3 -march=k8"' to it, basically the same format as make.conf, which is really just for setting shell variables.

That's basically all there is to it, and it has lots of uses, you can override many variables which you might set in make.conf, CFLAGS just being the most obvious one, but another fantastic one is EXTRA_ECONF, to which you can add extra --enable-foo or --disable-foo arguments to ./configure (presuming the ebuild uses econf).

One thing to bear in mind is that variables in these files override what you may find in make.conf, rather than add to them, so if you have just 'CFLAGS="-O3"' in the above example ffmpeg will be compiled without any -march set.

Another thing is not everything seems to work, one example of something which doesn't is ALSA_PCM_PLUGINS for media-libs/alsa-lib, and probably the same holds true for VIDEO_CARDS, LINGUAS and the like (run `emerge -v --info | grep USE_EXPAND` for a list), but most likely the reason for this is they are in fact just USE flags, and their real format is alsa_pcm_plugins_FOO, so adding alsa_pcm_plugins_rate and similar to /etc/portage/package.use should do the trick there.

----------

## desultory

Another option to query the state of USE_EXPAND would be portageq envvar USE_EXPAND, when checking the state of a single known variable it is somewhat faster.

----------

## boundless

 *stevenrobertson wrote:*   

> 
> 
> <snip>
> 
> Changes:
> ...

 

I have applied this with my Firefox insttallation, but in Ubuntu and with FF 3.0.5 and when I try to update FF with ubuntuzilla.py it gives an error like this

Backing up old Firefox preferences

Traceback (most recent call last):

  File "/usr/local/bin/ubuntuzilla.py", line 1146, in <module>

    bs.start()

  File "/usr/local/bin/ubuntuzilla.py", line 209, in start

    fi.start()

  File "/usr/local/bin/ubuntuzilla.py", line 236, in start

    self.install()

  File "/usr/local/bin/ubuntuzilla.py", line 601, in install

    self.backupProfile()

  File "/usr/local/bin/ubuntuzilla.py", line 757, in backupProfile

    self.checkDiskSpaceForBackup("~/.mozilla")

  File "/usr/local/bin/ubuntuzilla.py", line 384, in checkDiskSpaceForBackup

    requiredForBackup = int(self.util.getSystemOutput(executionstring="du -sk "+target+" |awk '{print $1}'"))

ValueError: invalid literal for int() with base 10: "du: cannot read directory `/home/kimme/.mozilla/firefox/koglgpp1.default/Cache': Permission denied"

How do I update FF with this tip enabled?

----------

## sts

It might also speed things up noticeably if you vacuum the databases after firefox is closed:

```
$ for i in ~/.mozilla/firefox/*.*/*.sqlite; do sqlite3 $i vacuum; done
```

----------

## nuhiNlow

i put the .pack_ffox.sh in my user cron AND in gnome's startup programs..

how would i get it to execute upon shutdown of gnome?

----------

## pdw_hu

 *lysergia wrote:*   

> i put the .pack_ffox.sh in my user cron AND in gnome's startup programs..
> 
> how would i get it to execute upon shutdown of gnome?

 

If by shutdown of gnome you mean turning off your computer then use /etc/conf.d/local.stop

----------

## Lowspirit

Tried this due to necessity because I have a raptor disk that's very loud and the disk reads during usage of Firefox would get ridiculous.

And I must say, succcess, startup is maybe only 1-2 seconds faster but usage overall I never hear my disk and certain elements that would clog it up before (using location bar etc) is just silky now, I use the method someone above mentions where I use my already mounted tmpfs that I have for my /tmp directory to just haul my profile to and then link my mozilla profile directory to that one, felt alot easier.

----------

## Dont Panic

 *pdw_hu wrote:*   

>  *lysergia wrote:*   i put the .pack_ffox.sh in my user cron AND in gnome's startup programs..
> 
> how would i get it to execute upon shutdown of gnome? 
> 
> If by shutdown of gnome you mean turning off your computer then use /etc/conf.d/local.stop

 

Since /etc/conf.d/local.stop runs as root, is there a generic way to put this in /etc/conf.d/local.stop, and have it work for my normal user (that doesn't involve hard-coding the normal user)?

----------

## razze

Thanks!

This was a great tip! On my rig (amd X2 3800+, 2G mem) the difference is clearly noticeable and it feels like a new computer.

----------

## shgadwa

I get stuck here....

 *Quote:*   

> localhost firefox # $ "${HOME}/.pack_ffox.sh"
> 
> bash: $: command not found
> 
> localhost firefox # ${HOME}/.pack_ffox.sh 
> ...

 

I must have done something wrong. I thought I was supposed to create a ${HOME}/.pack_ffox.sh file.... right?

----------

## shgadwa

I do not get it. The thing is, I do not even have a profile directory.... I have a file called profiles.ini. 

I realize I'm supposed 'run the script' not save the file.... I think. But I cannot run the script too easily either.

 *Quote:*   

> localhost firefox # #!/bin/bash 
> 
> localhost firefox # 
> 
> localhost firefox # # Change this to match your correct profile 
> ...

 

----------

## truc

 *belikeyeshua wrote:*   

> ...

 

ls -l ~/.mozilla/firefox  :Question: 

----------

## shgadwa

 *Quote:*   

> lrwxrwxrwx 1 root root    26 Mar 18 09:13 firefox -> /tmp/.private/root/firefox
> 
> drwx------ 6 root root  4096 Mar 18 09:13 hzotbwlp.default
> 
> -rw-r--r-- 1 root root 10240 Mar 18 08:24 packed.tar
> ...

 

I dunno... maybe its working now, or maybe I have to reboot or something or the other.

----------

## truc

copy the script somewhere, then modify the PROFILE variable, so that it's equal to "hzotbwlp.default"

close firefox, run the script, look at the output of the 'mount' command, then read this thread again, till you get something

----------

## shgadwa

 *Quote:*   

> localhost ~ # #!/bin/bash 
> 
> localhost ~ # 
> 
> localhost ~ # # Change this to match your correct profile 
> ...

 

----------

## shgadwa

And I do not even have a profile directory... I do have a file called profiles.ini in the /firefox folder.

EDIT: Sorry about the double post... I will have to read it a few times then when I get time. Later.

Thanks.

~ShawnLast edited by shgadwa on Wed Mar 18, 2009 1:01 pm; edited 1 time in total

----------

## truc

No need to double-post.

here is a hint:

 *truc wrote:*   

> then read this thread again, till you get something

 

----------

## shgadwa

OK............... I read this thread a few times. I think it works, but then again, I think it does not work. That is to say, I do not get any errors but it never creates or mounts a directory anywhere that I can see and my .mozilla/firefox/ profile directory just keeps filling up with more cache and stuff. I take its not working. To be honest I'm tired of reading the same thing over and over again. Oh well, thats alright... its not like its super slow anyway.

----------

## Enlight

 *belikeyeshua wrote:*   

>  *Quote:*   localhost ~ # #!/bin/bash 
> 
> localhost ~ # # Change this to match your correct profile 
> 
> localhost ~ # PROFILE="profiles.ini" 
> ...

 

This is where you're wrong! profile is [something].default in ~/.mozilla/firefox/

----------

## Sadako

 *Enlight wrote:*   

>  *belikeyeshua wrote:*    *Quote:*   localhost ~ # #!/bin/bash 
> 
> localhost ~ # # Change this to match your correct profile 
> 
> localhost ~ # PROFILE="profiles.ini" 
> ...

 Howsabouts this?

```
PROFDIR="${HOME}/.mozilla/firefox/"

PROFILE="${PROFDIR}/$(grep Path= "${PROFDIR}/profiles.ini" | cut -d = -f 2)"
```

Assuming you only have one profile defined within profiles.ini...

----------

## shgadwa

Yes, I figured that out.... after reading the thread a few times.   :Laughing: 

I have used the right file (blahblah.default)... but it still does not work.

----------

## Sadako

 *Hopeless wrote:*   

>  *Enlight wrote:*    *belikeyeshua wrote:*    *Quote:*   localhost ~ # #!/bin/bash 
> 
> localhost ~ # # Change this to match your correct profile 
> 
> localhost ~ # PROFILE="profiles.ini" 
> ...

 Actually, the above is completely unnecessary, and rather silly really.

All you really need is this;

```
PROFILE="${HOME}/.mozilla/firefox/*.default/"
```

----------

## Gentooser

Cannot edit crontab  :Sad: 

```

/bin/sh: /usr/bin/vi: No such file or directory

crontab: "/usr/bin/vi" exited with status 127
```

----------

## Dont Panic

It looks like something has gone amiss with your default editor setting.

Normally, in Gentoo, this is set for /usr/bin/nano.

One possibility is that your default editor was changed to vim, but the package app-editors/vim was either not installed or un-installed.

You also may want to edit your /etc/rc.conf file, and change your default editor to one that is installed (/usr/bin/nano is usually the default).

----------

## loudmax

I rewrote stevenrobertson's script to include compression and some error checking.  Compression isn't strictly necessary, but it's desirable for machines with SSD media such as netbooks.

```

#!/bin/bash

################################################################################################

## Firefox tmpfs utility

#  see http://forums.gentoo.org/viewtopic-t-717117.html

#

# 1. check environment:

#   a. entry in /etc/fstab

#   b. profile dir is empty if not mounted tmpfs

#   if either condition is false, print setup info

# 2. check pack direction:

#   tmpfs is mounted

#       pack it to archive

#   tmpfs not mounted

#       mount and unpack

#

################################################################################################

## Change this to match your correct profile 

#  If blank, this script will grab whatever profile is most recent

#

PROFILE=""

FFOX_HOME="${HOME}/.mozilla/firefox"

## Preferred compression utility

#  We're going for speed, the options are: none, gzip or lzop

#  If blank, the script will select lzop if available or default to gzip

#

COMPRESSOR=""

export GZIP='--fast'    # option for gzip

## get more recent profile in home dir if not defined

#

if [[ ${PROFILE} == "" ]]; then

    PROFILE=$( basename $( ls -rdt ${HOME}/.mozilla/firefox/*.default | tail -n 1 ) )

fi

## Check that environment is set up right

#  a. We found the ffox profile

#  b. There should be an entry in /etc/fstab

#  c. The profile should be an empty directory if the tmps is unmounted

#

FAILED_CHECKS=0

if [[ ${PROFILE} == "" ]]; then

    echo "Cannot find firefox profile directory"

    exit 3

fi

if [[ $( grep "${FFOX_HOME}/${PROFILE}" /etc/fstab ) == "" ]]; then

    FAILED_CHECKS=1

fi

if test -z "$(mount | grep -F "${FFOX_HOME}/${PROFILE}" )"; then

    if [[ -d "${FFOX_HOME}/${PROFILE}" ]]; then

        FAILED_CHECKS=$( ls ${FFOX_HOME}/${PROFILE}/* 2> /dev/null| wc -l )

    fi

fi

if [[ ${FAILED_CHECKS} != 0 ]]; then

    echo "See the Gentoo forums for an explanation of how this works: http://forums.gentoo.org/viewtopic-t-717117.html"

    echo ""

    echo "Make sure a line like this one is in /etc/fstab:"

    GID=$( awk -v FS=: '/'"${USER}"'/{print $4 ; quit}' /etc/passwd )

    echo "firefox ${FFOX_HOME}/${PROFILE} tmpfs noauto,user,exec,uid=${UID},gid=${GID} 0 0"

    echo ""

    echo "Exit firefox and tar a copy of the profile:"

    echo "  cd ${FFOX_HOME}"

    echo "  tar -czpf ${PROFILE}.tar.gz ${PROFILE}   #(this is for gzip compression)"

    echo "      OR"

    echo "  tar -cp ${PROFILE} | lzop -c > ${PROFILE}.tar.lzo   #(this is for lzop compression)"

    echo "      OR"

    echo "  tar -cpf ${PROFILE}.tar ${PROFILE}   #(this is for no compression)"

    echo "Back up your profile and create an empty directory:"

    echo "  mv -i ${PROFILE} ${PROFILE}.bak && mkdir ${PROFILE}"

    exit 2

fi

## define how to pack archive

#

PACKLZO="tar --exclude '.unpackt' -C ${FFOX_HOME} -cp \"${PROFILE}\" | lzop -c > ${FFOX_HOME}/${PROFILE}.tar.lzo"

UNPACKLZO="lzop -cd \"${FFOX_HOME}/${PROFILE}.tar.lzo\" | tar -C ${FFOX_HOME} -xp"

PACKGZP="tar --exclude '.unpackt' -C ${FFOX_HOME} -czpf ${FFOX_HOME}/${PROFILE}.tar.gz \"${PROFILE}\""

UNPACKGZP="tar -C ${FFOX_HOME} -xzpf ${FFOX_HOME}/${PROFILE}.tar.gz"

PACKTAR="tar --exclude '.unpackt' -C ${FFOX_HOME} -cpf ${FFOX_HOME}/${PROFILE}.tar \"${PROFILE}\""

UNPACKTAR="tar -C ${FFOX_HOME} -xpf ${FFOX_HOME}/${PROFILE}.tar"

## set pack/unpack command based on available utilities

#

PACKCMD=""

UNPACKCMD=""

if [[ ${COMPRESSOR} == "" ]]; then

    if [[ $( which lzop ) != "" ]] && [[ -f ${FFOX_HOME}/${PROFILE}.tar.lzo ]] ; then

        PACKCMD=${PACKLZO} 

        UNPACKCMD=${UNPACKLZO}

    else

        PACKCMD=${PACKGZP}

        UNPACKCMD=${UNPACKGZP}

    fi

elif [[ ${COMPRESSOR} == "lzop" ]]; then

    if test -z "which lzop"; then

        echo "Could not find lzop"

        exit 4

    fi

elif [[ ${COMPRESSOR} == "gzip" ]]; then

    PACKCMD=${PACKGZP}

    UNPACKCMD=${UNPACKGZP}

elif [[ ${COMPRESSOR} == "none" ]]; then

    PACKCMD=${PACKTAR}

    UNPACKCMD=${UNPACKTAR}

fi

## Check mount point

#

if test -z "$(mount | grep -F "${FFOX_HOME}/${PROFILE}" )"; then

    mount "${FFOX_HOME}/${PROFILE}"

    if [[ $? != 0 ]]; then

        echo "Failed to mount tmpfs"

        exit 1

    fi

fi

## Things look good, so pack if running profile found, or unpack if profile empty

#

if [[ -f "${FFOX_HOME}/${PROFILE}/.unpackt" ]]; then 

    echo -n "tarring firefox... "

    START_TIME=$( date +%s )

    bash -c "${PACKCMD}"

    if [[ $? != 0 ]]; then

        echo "Failed to pack the profile"

        exit 4

    fi

    END_TIME=$( date +%s )

    PACK_TIME=$(( ${END_TIME} - ${START_TIME} ))

    echo "done in ${PACK_TIME} seconds!"

else

    bash -c "${UNPACKCMD}"

    echo "unpacking!"

    if [[ $? != 0 ]]; then

        echo "Failed to unpack the profile"

        exit 5

    fi

    touch "${FFOX_HOME}/${PROFILE}/.unpackt"

fi

```

Last edited by loudmax on Mon Apr 13, 2009 2:58 pm; edited 1 time in total

----------

## truc

I haven't read the whole script, but, I don't see why you launch a new bash process to execute eg  "${UNPACKCMD}" 

```
bash -c "${UNPACKCMD}"
```

Also, (as a side note  :Wink: ):

You can replace this:

```
grep -m 1 ${USER} /etc/passwd | awk 'BEGIN{FS=":"}{print $4}'
```

with:

```
awk -v FS=: '/'"${USER}"'/{print $4 ; quit}' /etc/passwd
```

EDIT: now that I think about what you really want, I think you can even replace the whole command with 

```
id -g
```

----------

## loudmax

 *truc wrote:*   

> I haven't read the whole script, but, I don't see why you launch a new bash process to execute eg  "${UNPACKCMD}"

 

To tell the truth, I'm not sure why either.  If I try to execute it directly without wrapping bash around it, I get this error:

```
$ packfox.sh 

lzop: cannot use both `-c' and `-p'

Usage: lzop [-dxlthIVL19] [-qvcfFnNPkUp] [-o file] [-S suffix] [file..]

unpacking!
```

or this error:

```
$ packfox.sh 

packfox.sh: line 137: lzop -cd "/home/user/.mozilla/firefox/abcd1234.default.tar.lzo" | tar -C /home/user/.mozilla/firefox -xp: No such file or directory
```

I get errors regardless of whether I'm using lzop, gzip, or no compression.  If I wrap the command inside a spawned bash process, it comes out fine.

 *truc wrote:*   

> You can replace this:
> 
> ```
> grep -m 1 ${USER} /etc/passwd | awk 'BEGIN{FS=":"}{print $4}'
> ```
> ...

 

Oh yes, that is nice.  I'll update the script.

----------

## boerKrelis

Here's a rewrite which uses inotify, so it only tars whenever anything changes.

Read the comments in the file to find out how to handle this.

```

#!/bin/bash

# Save this script as 'packfox' and hard/symlink it as 'packfox-daemon'

# (or the other way around) in the same dir.

# 'packfox' will invoke the packing.

# 'packfox-daemon' will run a loop, watching for changes, calling 'packfox' if any.

# both incantations will do checks, mounting, and unpacking.

# Change this to match your correct profile

PROFILE="bling"

PFDIR="${HOME}/.mozilla/firefox"

# Tar every .. seconds (regardless of changes)

TMOUT="900"

# But not more often than every .. seconds (regardless of changes)

TMMIN="60"

# Regex for which files not to act on when they're changed.

# Use inotifywait -m -e modify -e move -e create -e delete --exclude '(/Cache/)' -r your_profile_dir

# and do some browsing to determine which regex will be right for YOU.

IEXCL="(.sqlite-journal$)|(\-log.txt$)|(cookies.sqlite$)|(sessionstore\-[0-9].js$)|(/weave/)|(/Cache/)"

# Have you read everything and have you made the necessary adjustments? Then remove the line below ;-)

echo "I should read the comments and adjust the variables before running this script" && exit 2

# No user servicable parts below this line.

TGT="${PFDIR}/${PROFILE}"

function seppuku(){

  echo "${1}"

  exit 2

}

test -d "${PFDIR}" || seppuku "Profile dir doesn't exist"

if [ -z "$(mount -t tmpfs | grep -F "${TGT}" )" ]

then

    mount "${PFDIR}/${PROFILE}" || seppuku "Mounting of profile's tmpfs failed; check fstab"

fi

test -f "${TGT}/.unpacked" || tar -xpf "${PFDIR}/packed.tar" -C "${PFDIR}" && touch "${TGT}/.unpacked"

if [ "$(basename ${0})" == "packfox-daemon" ]

then

  which inotifywait >/dev/null 2>&1 || seppuku "Install sys-fs/inotify-tools first".

  while true

    do inotifywait -q -q -t ${TMOUT} -e modify -e move -e create -e delete --exclude "${IEXCL}" \

    -r "${PFDIR}/${PROFILE}"; "$(dirname "${0}")/packfox"; sleep ${TMMIN}

    done

  exit

fi

cd "${PFDIR}"

tar --exclude '.unpacked' -cpf "${PFDIR}/packed.tmp.tar" "${PROFILE}"

mv "${PFDIR}/packed.tar" "${PFDIR}/packed.tar.old"

mv "${PFDIR}/packed.tmp.tar" "${PFDIR}/packed.tar"

```

----------

## iamboredr

it would affect the browsers speed?

----------

## gigio

Hi, 

I'm very interested in this,

Could anyone please post the shell commands to run the script in Mac OS X 10.4 ?

I tried to follow all of your instructions, but i get this error when mounting tmpfs: "unknown special file or file system."

It probably has to do with fstab,

Anyone can help?

Thank you very much in advance  :Smile: 

----------

## truc

 *gigio wrote:*   

> Hi, 
> 
> I'm very interested in this,
> 
> Could anyone please post the shell commands to run the script in Mac OS X 10.4 ?
> ...

 

googling for tmpfs osx ~brings this link: Blazing Fast Firefox using OSX RamDisk

 :Wink: 

----------

## Ch00k

Well, I wonder why would you need a cron entry for the script. Wouldn't it be enough to execute the script for just two times: on login (boot) and on logout (shutdown). What files do I have to add this script to? Are they .bash_profile and .bash_logout?

----------

## Ch00k

 *Hopeless wrote:*   

> One thing to bear in mind is that variables in these files override what you may find in make.conf, rather than add to them, so if you have just 'CFLAGS="-O3"' in the above example ffmpeg will be compiled without any -march set.

 

I also have a question regarding this post. Does the above mean that if you do not set CHOST, MAKEOPTS, GENTOO_MIRRORS etc, then they will leave unset for this specific package? Well, without GENTOO_MIRRORS you will not be able to even fetch it  :Smile: 

----------

## boerKrelis

Ch00k, you're right wrt needing to run the script >2 times. It depends on how much of your browsing history, open tabs, bookmarks, entered passwords, stored cookies you are willing to lose if the unforeseen happens (eg you crash your machine).

If you want to avoid doing unnecessary work (tarring even though nothing's changed) and want to control upper and lower bounds to how often the tarring should take place I'd recommend my inotify script posted in this thread.

Your ~/.bash_login only gets sourced when you execute bash as a login shell. From this it follows that that is not a good place to call the script from, unless you don't boot into X and bash is your login shell.

I run my 'packfox-daemon' from an XDG entry in ~/.config/autostart .

 *Quote:*   

> 
> 
> I also have a question regarding this post. Does the above mean that if you do not set CHOST, MAKEOPTS, GENTOO_MIRRORS etc, then they will leave unset for this specific package? Well, without GENTOO_MIRRORS you will not be able to even fetch it 
> 
> 

 

If you don't override stuff on the commandline they will be taken from make.conf . If not found there, portage will leave them unset or, in some cases, make up something by itself.

This can be illustrated by doing something like

```
CFLAGS="-foobar" emerge --info

```

and observing the difference between this and a regular

```
emerge --info

```

You can override any variable. This is a generic mechanism. Observe the output from

```
env
```

That's all the variables assigned in your current environment (such as your current bash shell).

You can figure out how it works by observing the difference in output between

```
/usr/bin/which ls
```

and

```
PATH="/tmp" /usr/bin/which ls
```

You can make variables persistent in the current environment by using export. For instance, try

```
export PATH="/tmp"
```

and observe that it has now become quite difficult to do stuff in this particular shell ;-)

----------

## Ch00k

boerKrelis, many thanks for your reply. Though, I actually mean the following:

 *Quote:*   

> Sure, tbh I can't even remember how/where I learned about it, but I know full well about the lack of documentation for this feature.
> 
> Take (for example) media-video/ffmpeg, if you have CFLAGS="-O2 -march=k8" in make.conf, but wish to have ffmpeg compiled with -O3, you'd create the file (and parent directories) '/etc/portage/env/media-video/ffmpeg', and simply add 'CFLAGS="-O3 -march=k8"' to it, basically the same format as make.conf, which is really just for setting shell variables.
> 
> That's basically all there is to it, and it has lots of uses, you can override many variables which you might set in make.conf, CFLAGS just being the most obvious one, but another fantastic one is EXTRA_ECONF, to which you can add extra --enable-foo or --disable-foo arguments to ./configure (presuming the ebuild uses econf).
> ...

 

So... if you create this /etc/portage/env/media-video/ffmpeg file and post there, say, CFLAGS="-O2 -march=k8", then will all the other variables, like CHOST, MAKEOPTS, GENTOO_MIRRORS be taken from /etc/make.conf, or will they be left unset. From the "One thing to bear in mind is that variables in these files override what you may find in make.conf, rather than add to them, so if you have just 'CFLAGS="-O3"' in the above example ffmpeg will be compiled without any -march set." I concluded that they will be left unset. Or maybe the files in /etc/portage/env are intended to be used for posting into them the CFLAGS variable only, and all the rest is taken from /etc/make.conf? 

Sorry to post this in an unrelated thread, but I'm really concerned in learning this feature  :Smile: 

----------

## loki99

Thx for the tip! It reduced the initial startup time by 50% for me and the whole thing just feel a tad faster.  :Smile: 

----------

## Sadako

 *Ch00k wrote:*   

> boerKrelis, many thanks for your reply. Though, I actually mean the following:
> 
>  *Quote:*   Sure, tbh I can't even remember how/where I learned about it, but I know full well about the lack of documentation for this feature.
> 
> Take (for example) media-video/ffmpeg, if you have CFLAGS="-O2 -march=k8" in make.conf, but wish to have ffmpeg compiled with -O3, you'd create the file (and parent directories) '/etc/portage/env/media-video/ffmpeg', and simply add 'CFLAGS="-O3 -march=k8"' to it, basically the same format as make.conf, which is really just for setting shell variables.
> ...

 Sorry I didn't reply sooner, updates to this thread weren't bumping it in my "egosearch".

Anyways, variables like CHOST & co will only be overridden if you set them in the /etc/portage/env/cat/package file, ie if you don't set them they'll use what's set in make.conf.

The point I was trying to make was that you can't just add new flags to a variable like CFLAGS, ie if you have CFLAGS="-march=i686 -O2" in make.conf and you want to add -fomit-frame-pointer for one particular package via /etc/portage/env, you need to add CFLAGS="-march=i686 -O2 -fomit-frame-pointer" rather than just CFLAGS="-fomit-frame-pointer", as with the latter there'll be no -march or optimization switch passed to gcc during compile.

However, only the flags you explicitly set in the env file will override those in make.conf, meaning if you don't set CHOST or whatever in that file it'll still use the CHOST setting in make.conf, regardless of whatever else you have set in the env file.

A hope this clears it up a little, sorry it was kinda vague before.

----------

## El_Goretto

Hi everyone,

I wanna use this script, but I dont understand why using so dirty "hacks" (local.stop or crontab... argh) to ensure that the script is run after ff is closed... 

Why not simply use a simple "wrapper", such as this totally complex:

```
#!/bin/bash

/usr/local/bin/pack_ffox.sh

/usr/bin/firefox $*

/usr/local/bin/pack_ffox.sh

```

With a generic pack_ffox.sh using Hopeless modification: 

```
#!/bin/bash

PROFDIR="${HOME}/.mozilla/firefox"

PROFILE="$(grep Path= "${PROFDIR}/profiles.ini" | cut -d = -f 2)"

cd "${HOME}/.mozilla/firefox"

if test -z "$(mount | grep -F "${HOME}/.mozilla/firefox/${PROFILE}" )"

then

    mount "${HOME}/.mozilla/firefox/${PROFILE}"

fi

if test -f "${PROFILE}/.unpacked"

then

    tar --exclude '.unpacked' -cpf packed.tmp.tar "$PROFILE"

    mv packed.tar packed.tar.old

    mv packed.tmp.tar packed.tar

else

    tar xpf packed.tar &&\

    touch "${PROFILE}/.unpacked"

fi 

```

Or did I miss something?

----------

## truc

and what if your computer hangs? you're losing, among other things, the history since the previous backup?

----------

## El_Goretto

 *truc wrote:*   

> and what if your computer hangs? you're losing, among other things, the history since the previous backup?

 

It is true with the local.stop method too isn't it?

If the computer is faily unstable I assume that both wrapper and crontab should be used... (but why using an unstable computer and trying to make it faster rather than fixing it first?) Otherwise wrapper should be enough IMHO.

----------

## truc

well, I may have misunderstood you a little, I thought this thread was about calling the script through a cronjob, and that's all. I didn't know about the local.{start,stop} method.

Anyway, I'm personnally calling the, let's say, firefox-tmpfs script, first in ~/.xinitrc, then in a cronjob, and with a wrapper (kind of alias ff="firefox; firefox-tmpfs")

----------

## Compintuit

So... If I do this, having a 44MB places.sqlite file will no longer make searching my history take about 10 secs? Would we now be talking milliseconds? Because that would be nice... but I'm still a gentoo noob, so I think I'll have to wait a bit before I try. But this has definitely worked well for some people?

----------

## Evincar

 *Compintuit wrote:*   

> So... If I do this, having a 44MB places.sqlite file will no longer make searching my history take about 10 secs? Would we now be talking milliseconds? Because that would be nice... but I'm still a gentoo noob, so I think I'll have to wait a bit before I try. But this has definitely worked well for some people?

 

It works, indeed, and the difference here is abysmal. From 3-4 seconds chokes to near instantaneous seeking.

----------

## loudmax

I started a Github project based on stevenrobertson's script.  The most significant changes I added are compression, sqlite vacuuming, and printing a nice usage message.  It's available here: http://github.com/nickaubert/QPFox/tree/master

----------

## Bircoph

I don't see great benefit from this on my system.

I moved .firefox to /dev/shm and first startup time dropped from ~2.5 secs to 2.0 secs, repeated startups doesn't differ at all. Anyway, this is filesystem's job to cache I/O and ext4 does this in a nice way.

----------

## Bill Cosby

Agreed, with ext4 I hardly notice any improvement.

----------

## krinpaus

 *Bircoph wrote:*   

> I don't see great benefit from this on my system.
> 
> I moved .firefox to /dev/shm and first startup time dropped from ~2.5 secs to 2.0 secs, repeated startups doesn't differ at all. Anyway, this is filesystem's job to cache I/O and ext4 does this in a nice way.

 

I too, tried this "solution", among MANY other combos, to try and improve firefox performance,

especially once updating to FF 3.5.x, with no meaningful result. (I've been running reiserfs

for years on most partitions except /boot and my media collection (xfs), and that combo

has suited me and all the systems I touch fine (except Oracle DB's those aren't on Gentoo, sadly)).

Employing NoScript and Adblock and Flashblock only helped slightly, Flashblock moreso.

. It's when I bit the bullet (lose all those cookies, etc...) and moved .mozilla to .mozilla-old 

and restarted that performance improved. Evidently too much carry-over "crud" from previous versions, 

including my customized settings, weren't (rightfully) in FF's best performance "interest". 

I reimported my bookmarks and went back to setting up my unique logins for each site, and

all is well, I am much more satisfied (with Flashblock/NoScript/Adblock, performance or not...).

----------

## waterloo2005

firefox /home/steven/.mozilla/firefox/abcd1234.default tmpfs size=128M,noauto,user,exec,uid=1000,gid=100 0 0

here uid gid is about steven ?

I want to run .pack_ffox.sh when I reboot and shutdown computer .

How to do it ?

Do i need to use ordinary user to run .pack_ffox.sh ?

I know there is /etc/conf.d/local.stop , but all commands in it run as root .

How to run as ordinary user in  /etc/conf.d/local.stop ? 

thanks

----------

## pierro78

 *stevenrobertson wrote:*   

> 
> 
> set browser.safebrowsing.enabled to false
> 
> set browser.safebrowsing.malware.enabled to false
> ...

 

Wow I've used the 2 above settings + browser.cache.disk.enable set to false on my gentoo install on a slow (2MB/s write) sdhc card (using ext4 without journal) and I can already see a big speed improvement ! much less annoying slowdowns ... thanks for the tip !

PS :

found some more tweaks to test on my slow SDHC card gentoo install : 

- toolkit.storage.synchronous set to 0 ( http://www.roytanck.com/2009/04/05/more-eee-pc-firefox-speed-tweaks/ )

- browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0 (found on http://startupmeme.com/the-coolest-firefox-aboutconfig-tricks/ )

- using the SQLite Manager, under the DB Settings tab, change the "temporary data store" setting to "memory" ( http://forums.mozillazine.org/viewtopic.php?f=7&t=696145 )

- history set to max 21 days

PS2 :

eventually, even after I applied all the above tweaks, I ended using the initial tip of this thread because I still had slowdowns due to the slowness of my SDHC card. My firefox profile is about 25MB so a 64MB tmpfs is more than enough (that's a compressed tar of less than 7MB). Now my firefox is very fast and smooth  :Smile:  ... thanks again for the tip !

----------

## tclover

This a simple script to take care of everything. 

 *Quote:*   

> #!/bin/sh
> 
> #~/.ffp-pack.sh
> 
> PF=""
> ...

 

If no profile is set, the script will take care of it, mount the tmpfs and unpack the profile. Of course you'll had to manually rm your profile... The tmpfs will just be mounted over your original profile dir. There's no need for whatever fstab line. Just add the script in bashrc or in the autostart applications, so you can start browsing after loggin.

EDIT: YOU HAVE TO MANUALLY ARCHIVE YOUR PROFILE THE FIRST TIME [and rm it, because you won't need it anymore].

----------

## patrix_neo

 *pierro78 wrote:*   

>  *stevenrobertson wrote:*   
> 
> set browser.safebrowsing.enabled to false
> 
> set browser.safebrowsing.malware.enabled to false
> ...

 

I am from a world of security-first. So I am just asking - Is this good practice? I am just curious how this will affect my browsing if I do this.

----------

