CrunchBang Linux

Shinkanzen

#! CrunchBanger

Registered: 2009-01-30

Posts: 130

Interesting FF optimizations

http://www.verot.net/firefox_tmpfs.htm
http://webupd8.blogspot.com/2009/05/spe … le-in.html

jackbang

#! CrunchBanger

Registered: 2009-05-28

Posts: 244

Re: Interesting FF optimizations

Interesting links, thanks.

FF 3.5 is a huge improvement over 3.0.10 for me.  Really a quite noticeable speed-up.

I would think some kind of copy-on-write union_fs with frequent syncs would be ideal for putting the profile in ram.

The tradeoff is always that you risk losing a few minutes of updates that haven't  yet been commited to disk.  It's always sold as "are your last 5 minutes of bookmarks really that important?" - but I suspect the reality is that a power failure could actually result in db corruption, and you end up losing the last 5 years, not minutes.

I don't know why we don't have battery-backed RAM or disk cache in PCs, particularly laptops where there's a battery anyway.  It would solve many of these commit-transaction-to-disk performance issues at a stroke.  SAN storage servers use it to hold journals etc.

Last edited by jackbang (2009-06-24 15:45:03)

iggykoopa

Script Master

Registered: 2008-12-13

Posts: 1,480

Re: Interesting FF optimizations

or once mram becomes mainstream we won't have to worry about a battery can't wait (or any other type of nv-ram)

---

I say never be complete, I say stop being perfect, I say lets evolve, let the chips fall where they may.

jackbang

#! CrunchBanger

Registered: 2009-05-28

Posts: 244

Re: Interesting FF optimizations

Yep, mram, racetrack memory, phase change, etc, etc, etc, are all coming.  But we could have had battery backed ram cache/journals at least 10 years ago, and in fact we did on storage servers, etc.

someone is doing external journaling with flash, here:
http://insights.oetiker.ch/linux/extern … al-on-ssd/

In theory, once the data has been written to journal, that's it, job done, data committed, as far as the app is concerned, and it can get on with it.  The OS then has to take the linear records in the journal, and update the various disk blocks, "in the background".  I don't know if linux ext3 actually does separate the two phases or not, but I guess from the findings above, that it improves performance, and especially it stops those nasty system freezes whenever you get heavy writes, proves it does.

There's also the microsoft readyboost or whatever its called, which uses flash as cache - I don't think there's a linux equivalent.

Last edited by jackbang (2009-06-27 07:31:02)

Jdemnahouby

#! CrunchBanger

From: France, but living in Prague

Registered: 2009-04-13

Posts: 222

Re: Interesting FF optimizations

Can somebody explain me the difference in terms of performance, speed between the tmpfs modification and the following modification in about:config:

browser.cache.memory.enable;true
browser.cache.memory.capacity= 65536 or more (according to RAM size)

I saw many many blogs writing about tmpfs or equivalent, in one blog they also propose the possibility in about:config and said that it has the same effect in terms of speed, is it true?

Jdemnahouby

#! CrunchBanger

From: France, but living in Prague

Registered: 2009-04-13

Posts: 222

Re: Interesting FF optimizations

another possibility:
1) Edit /etc/fstab
add this line :
tmpfs /tmp tmpfs defaults 0 0
2) suppress Cache ~/.mozilla/firefox/1jsw2aqf.default/Cache
sudo rm -Rf ~/.mozilla/firefox/1jsw2aqf.default/Cache
3)Put symbolic link
ln -s /tmp ~/.mozilla/firefox/1jsw2aqf.default/Cache

It seems it works also

But which method is the most efficient?