My recent experience with Firefox's speed

May 30, 2011

I used to look a bit oddly at people who talked about Firefox being slow, because that wasn't my experience at all. My Firefox worked fast and stayed that way even when I left it running for months, and I usually attributed this to not allowing Javascript to run (I wrote about this a long time ago and I still stand by it). The idea of migrating to another browser for faster speed always sounded a bit odd; how much closer to instant responses could you really get?

(My Firefox was not the speediest thing going when running heavy Javascript, but then my machine itself is not the most modern and I wasn't too surprised by that.)

Then recently I upgraded from my personally compiled vintage 2006 Firefox (which was more or less some 3.0 alpha or beta version, built from the then current CVS source code) to a current Firefox 3.6. The result of this has given me a whole new appreciation of this issue, because my new Firefox is, shall we say, not speedy. In fact it's frequently decidedly pokey, with clear pauses every so often when I want it to do things like open new windows, follow links, or even scroll text. Many things seem to stutter or otherwise not work anywhere near as well as my old Firefox did.

I'm not sure what the cause of this bad performance is but my suspicion is on Firefox's new sqlite-based history database, which is known to have problems on Linux to start with. I keep a perpetual browsing history, so I have a very large history database (my home database sqlite file is 185 MBytes); I can believe that even checking it is kind of slow (especially if it involves actual disk IO). By contrast, Firefox's old history database basically kept everything in memory and seems to have worked fine for me despite the size.

(The obvious experiment is to temporarily throw away my history or drastically reduce its size, but that has certain downsides. I keep my large history because I find it very useful, after all.)

Sidebar: why I finally upgraded my old Firefox

The short answer is 'it seemed about time'. Two things pushed me over the edge; first, my old Firefox was crashing fairly frequently when I browsed LiveJournal, and second, it looked increasingly like I was going to have to give up xfs on Fedora because using xfs crashes the X server and the bug did not look like it was going to get fixed. My main reason for still using my old Firefox was that it was the last Firefox version that could use the fonts I like, but it needed xfs for other fonts; if I was going to have to give up xfs, I was effectively going to have to give it up anyways.

Comments on this page:

From at 2011-05-30 06:46:17:

I can highly recommend ext4 (on 2.6.30+, apparently) for better performance (comparing respective default settings).

Firefox 3 + ext3 on the EeePC's cheap SSD was absolutely terrible. ext4 on the same machine is much better. Firefox4 is possibly a notch better - the bookmark editor is definitely much less laggy (but there are of course unrelated regressions). Chrome is almost certainly another notch better. But I think ext3's default fsync() behaviour was the biggest problem.


By trs80 at 2011-05-31 09:37:30:

I hit this too when I upgraded from lenny to squeeze. My default browser is actually Chrome these days, simply because it doesn't crash (even once a month is too often with Firefo^Wiceweasel). I'm pretty sure Firefox 3.0 had the sqlite history DB, I'm not sure what slowed it down so much in 3.5.

By cks at 2011-05-31 13:41:18:

My old Firefox CVS build definitely did not have the sqlite history DB, although apparently it appeared early in the Firefox 3 release sequence.

From at 2011-05-31 21:04:22:

Phoronix picked up on this a while back, and pegged SQLite as the culprit as well. If you want to settle on the ugly hack option there are scripts out there to make the SQLite database operate from /dev/shm which should make it blisteringly fast. However you do have to remember to run the scripts to copy the database in and out of memory or you lose whatever history you had when you next restart.

Written on 30 May 2011.
« Getting the stages of the class namespace straight
How to fail at versioning »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon May 30 00:26:32 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.