Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[TIP] Firefox and tmpfs: a surprising improvement
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
stevenrobertson
n00b
n00b


Joined: 28 Oct 2008
Posts: 8

PostPosted: Fri Dec 05, 2008 6:30 am    Post subject: [TIP] Firefox and tmpfs: a surprising improvement Reply with quote

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



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
Back to top
View user's profile Send private message
SlashBeast
Retired Dev
Retired Dev


Joined: 23 May 2006
Posts: 2922

PostPosted: Fri Dec 05, 2008 10:14 am    Post subject: Reply with quote

Work for me, thx.

My fstab entry:
Code:
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. :) ), size for limit space, uid and gid for owner rights.

script:
Code:
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
Back to top
View user's profile Send private message
Cazzantonio
Bodhisattva
Bodhisattva


Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world

PostPosted: Fri Dec 05, 2008 12:14 pm    Post subject: Reply with quote

Isn't just enough to set browser.cache.disk.parent_directory=/dev/shm to cache files in tmpfs?
_________________
Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne
Back to top
View user's profile Send private message
M
Guru
Guru


Joined: 12 Dec 2006
Posts: 432

PostPosted: Fri Dec 05, 2008 2:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
zyko
l33t
l33t


Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany

PostPosted: Fri Dec 05, 2008 5:17 pm    Post subject: Reply with quote

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 :)

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.
Back to top
View user's profile Send private message
Cazzantonio
Bodhisattva
Bodhisattva


Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world

PostPosted: Sun Dec 07, 2008 10:01 am    Post subject: Reply with 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.
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
before bootmisc logger cron
}

#Directory for backups of di /var/log, /var/run e /var/lock
DATA_DIR_BACKUP=/var
#Max log size before rotation (in mb)
MAX_LOG_SIZE=50
#If you want to run the script as a daemon and check log size on time basis set this to "1"
DEMONIZED=0
#If DEMONIZED=1 select the time interval between checks
#Suffix is 's' for seconds, 'm' for minute, 'h' for hours and 'd' for days
CHECK_TIME=12h

backup() {
#backup and rotation of /var/log
cd /var
tar cvpf $DATA_DIR_BACKUP/log_bk.tar log/ &>/dev/null
chmod 600 $DATA_DIR_BACKUP/log_bk.tar
LOGSIZE=$(du -m $DATA_DIR_BACKUP/log_bk.tar|cut -f1)
echo "Log size = $LOGSIZE M, Rotating at $MAX_LOG_SIZE"
if [ $LOGSIZE -gt $MAX_LOG_SIZE ]; then
echo "Log size limit reached. Rotating logs"
/bin/rm `find /var/log -type f|grep -v "\.keep"|grep -v "emerge.log"`
touch /var/run/utmp; chgrp utmp /var/run/utmp; chmod 664 /var/run/utmp
/bin/mv $DATA_DIR_BACKUP/log_bk.tar $DATA_DIR_BACKUP/log_bk.tar_old -f
tar cvzpf $DATA_DIR_BACKUP/log_bk.tar log/ &>/dev/null
chmod 600 $DATA_DIR_BACKUP/log_bk.tar
fi
#backup /var/run
/bin/rm `find /var/run -type f -iname *.pid` -rf
/bin/rm /var/run/utmp -rf
touch /var/run/utmp; chgrp utmp /var/run/utmp; chmod 664 /var/run/utmp
tar cvpf $DATA_DIR_BACKUP/run_bk.tar run/ &>/dev/null
chmod 600 $DATA_DIR_BACKUP/run_bk.tar
#backup /var/lock
tar cvpf $DATA_DIR_BACKUP/lock_bk.tar lock/ &>/dev/null
chmod 600 $DATA_DIR_BACKUP/lock_bk.tar
#backup /var/spool/cron
tar cvpf $DATA_DIR_BACKUP/spool_cron_bk.tar spool/cron &>/dev/null
chmod 600 $DATA_DIR_BACKUP/spool_cron_bk.tar
}

restore() {
#restore /var/log
tar xvpf $DATA_DIR_BACKUP/log_bk.tar -C /var/ &>/dev/null
touch /var/run/utmp; chgrp utmp /var/run/utmp; chmod 664 /var/run/utmp
#restore /var/run
tar xvpf $DATA_DIR_BACKUP/run_bk.tar -C /var/ &>/dev/null
touch /var/run/utmp; chgrp utmp /var/run/utmp; chmod 664 /var/run/utmp
#restore /var/lock
tar xvpf $DATA_DIR_BACKUP/lock_bk.tar -C /var/ &>/dev/null
chmod 775 /var/lock
chown root:uucp /var/lock
#restore /var/spool/cron
tar xvpf $DATA_DIR_BACKUP/spool_cron_bk.tar -C /var/ &>/dev/null
chmod 750 /var/spool/cron
chown root:cron /var/spool/cron
#daemon
if [ $DEMONIZED - eq 1 ]; then
daemon
fi
}

daemon() {
while [ $DEMONIZED -eq 1 ]; do
LOGSIZE=$(du -ms /var/log|cut -f1)
if [ $LOGSIZE -gt $MAX_LOG_SIZE ]; then
echo "Log size limit reached. Rotating logs"
/etc/init.d/syslog-ng stop
/bin/rm `find /var/log -type f|grep -v "\.keep"|grep -v "emerge.log"`
touch /var/run/utmp; chgrp utmp /var/run/utmp; chmod 664 /var/run/utmp
/bin/mv $DATA_DIR_BACKUP/log_bk.tar $DATA_DIR_BACKUP/log_bk.tar_old -f
tar cvzpf $DATA_DIR_BACKUP/log_bk.tar log/ &>/dev/null
chmod 600 $DATA_DIR_BACKUP/log_bk.tar
/etc/init.d/syslog-ng start
fi
sleep $CHECK_TIME
done
}

start() {
ebegin "Restore /var/log, /var/run, /var/lock and /var/spool/cron"
restore
eend $?
}

stop() {
ebegin "Backup /var/log, /var/run, /var/lock and /var/spool/cron"
backup

# Remove files in /tmp
# REMOVEFILES=$(ls -AlQ /tmp/ |grep "\"" |cut -d"\"" -f2)
# cd /tmp/
# for i in $REMOVEFILES
# do
# rm /tmp/$i -rf
# done

eend $?
}

_________________
Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne
Back to top
View user's profile Send private message
niick
Tux's lil' helper
Tux's lil' helper


Joined: 09 Mar 2006
Posts: 93

PostPosted: Sun Dec 07, 2008 3:48 pm    Post subject: Reply with quote

Firefox starts so fast now! woot!

Thanks for the tip steven :)
Back to top
View user's profile Send private message
zyko
l33t
l33t


Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany

PostPosted: Sun Dec 07, 2008 6:20 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
kg4ysy
Apprentice
Apprentice


Joined: 08 Jul 2006
Posts: 183
Location: North Carolina

PostPosted: Sun Dec 07, 2008 9:33 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
stevenrobertson
n00b
n00b


Joined: 28 Oct 2008
Posts: 8

PostPosted: Sun Dec 07, 2008 9:36 pm    Post subject: Reply with quote

kg4ysy wrote:
It says something about missing binaries.


In fstab, 'user' implies 'noexec'. Add 'exec' to your mount flags for the tmpfs partiton.
Back to top
View user's profile Send private message
kg4ysy
Apprentice
Apprentice


Joined: 08 Jul 2006
Posts: 183
Location: North Carolina

PostPosted: Sun Dec 07, 2008 9:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Mon Dec 08, 2008 4:54 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
kg4ysy
Apprentice
Apprentice


Joined: 08 Jul 2006
Posts: 183
Location: North Carolina

PostPosted: Mon Dec 08, 2008 4:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Wed Dec 10, 2008 3:17 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Sadako
Advocate
Advocate


Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub

PostPosted: Thu Dec 11, 2008 7:46 am    Post subject: Reply with quote

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;
Code:
        RUNDIR="/var/run/mpd"
        if [ ! -e "${RUNDIR}" ]; then
                mkdir -m 750 "${RUNDIR}"
                chown mpd:audio "${RUNDIR}"
        fi

_________________
"You have to invite me in"
Back to top
View user's profile Send private message
brfsa
Tux's lil' helper
Tux's lil' helper


Joined: 01 Aug 2005
Posts: 121
Location: Brazil

PostPosted: Wed Dec 17, 2008 9:29 pm    Post subject: Reply with quote

I did it in OSX leopard..

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

Awesome!


Start Script:
Code:

#!/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:
Code:

#!/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...
Back to top
View user's profile Send private message
brfsa
Tux's lil' helper
Tux's lil' helper


Joined: 01 Aug 2005
Posts: 121
Location: Brazil

PostPosted: Wed Dec 17, 2008 9:31 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
stevenrobertson
n00b
n00b


Joined: 28 Oct 2008
Posts: 8

PostPosted: Wed Dec 17, 2008 9:43 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
brfsa
Tux's lil' helper
Tux's lil' helper


Joined: 01 Aug 2005
Posts: 121
Location: Brazil

PostPosted: Wed Dec 17, 2008 9:48 pm    Post subject: Reply with quote

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.

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


you welcome... ;)

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....
Back to top
View user's profile Send private message
brfsa
Tux's lil' helper
Tux's lil' helper


Joined: 01 Aug 2005
Posts: 121
Location: Brazil

PostPosted: Wed Dec 17, 2008 9:51 pm    Post subject: Reply with quote

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 :)
not from the hd.

that's cool

I will update my script.
Back to top
View user's profile Send private message
hoacker
Guru
Guru


Joined: 04 Aug 2007
Posts: 505
Location: Bürstadt, Germany

PostPosted: Wed Dec 17, 2008 10:28 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
justinkb
Apprentice
Apprentice


Joined: 23 Dec 2008
Posts: 161

PostPosted: Thu Dec 25, 2008 12:40 pm    Post subject: Reply with quote

couldn't you just symlink the *.sqlite files to a folder outside the tmpfs partition instead of disable the safebrowsing entirely?
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Sat Dec 27, 2008 5:37 am    Post subject: Reply with quote

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.... :P so who cares... :wink:
Back to top
View user's profile Send private message
avx
Advocate
Advocate


Joined: 21 Jun 2004
Posts: 2152

PostPosted: Sun Dec 28, 2008 4:56 pm    Post subject: Reply with quote

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 :)

Edit:
Time the creation of a tarball (tar -pcf ...) and a squashfs (mksquashfs ... -no-duplicates -no-progress) of my ~21mb .opera.
time:
Code:
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)
Back to top
View user's profile Send private message
dirk_salewski
Apprentice
Apprentice


Joined: 04 Jun 2003
Posts: 216
Location: Germany

PostPosted: Mon Dec 29, 2008 12:34 pm    Post subject: Reply with quote

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.
_________________
Egal was Du kochst: Karl Marx.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum