The Death of Firefox and Plugins?

Sat Oct 10 06:31:44 BST 2009

On Sat, Oct 3, 2009 at 11:38 PM, Derek Broughton <derek at pointerstop.ca> wrote:
> er, no, I don't.  He did't actually seem to be having any problems with it -
> he just said it wasn't up to snuff compared to recent offerings like Chrome.
> Well, of course it isn't, because he's using the LTS.  If he compared the
> _current_ firefox, I think he wouldn't feel the same way.  But neither that
> version of Firefox, nor Chrome, are likely to be on most corporate desktops.

A fairer comparison would be to compare the latest versions of each.
There is no "stable" version of Chrome, so lets compare the latest
development snapshot of each. I find that Chrome is much more
responsive than Namoroka (firefox alpha) 3.6a1, firefox-3.5 and
firefox-3.0. But, first some background information.

I have found that even firefox 3.5 can freeze for half a second under
normal use. I find it very annoying that firefox can feel sluggish
even when I am  just typing plain ASCII text. Chrome does not suffer
from this problem, my online browser  responsiveness benchmark [1]
shows Chrome under load outperforming Firefox-3.5 when idle [2]. I
have mostly switch to the development version of Chrome, primarily for
this reason.

This is in part because because Firefox-3.5 is not multi-threaded. I
thought that 3.6 was going to be multi-threaded, although I can't
actually find an announcement. In any case 3.6a1 does appear to be
faster, however it still isn't as close to being real time as Chrome.
Compare the following delays in ms, and note that the script has an
intentional pause of 20ms, so it is impossible to do better than this.
Even without looking at the numbers we see that Chrome stays in the
double digits while Namoroka has delays of over 150ms. A delay of
150ms isn't that bad, but note that the browser is idle.

Namoroka (firefox prerelease) 3.6a1
26, 136, 26, 24, 56, 166, 29, 24, 23, 153, 153
26, 24, 25, 154, 24, 24, 24, 159, 25, 25, 25

Chromium 4.0.211.2
23, 23, 23, 28, 32, 31, 28, 22, 22, 24, 24
24, 23, 27, 22, 27, 21, 23, 22, 22, 22, 22

The numbers are milliseconds of delay after asking for 20ms of sleep
in javascript. Each number is generated by taking the maximum delay
over a period of ten seconds. In each case the browser was idle with
Gmail running in the background.

Now look what happens when I put the browsers under load by moving the
windows around furiously. Namoroka gets a delay of over one second
while Chrome still stays well withing the double digits.

Namoroka (firefox prerelease) 3.6a1
37, 35, 162, 164, 161, 31, 32, 33, 130, 33, 33
31, 244, 233, 163, 211, 1051, 176, 152, 164, 155, 155

Chromium 4.0.211.2
41, 30, 55, 32, 31, 29, 28, 38, 34, 26, 26
32, 38, 30, 34, 32, 26, 43, 28, 49, 65, 65

I then ran the Sunspider-0.9 [3] benchmarks giving me 2220ms, 1800ms
and 874ms for ff-3.5, 3.6a1 and Chrome respectively. We see below that
3.6a1 is better at stopping this heavy javascript use from reducing
responsiveness, but it is still much less responsive than Chrome:

3.5:     595, 265, 292, 291, 270, 270, 208, 230, 200, 237, 237
3.6a1: 231, 165, 219, 185, 203, 236, 203, 234, 197, 214, 214
Crom: 24, 40, 39, 31, 50, 40, 31, 37, 27, 25, 25

This benchmark could be unfair in any number of ways. Maybe one
browser has more debugging crud in its development version than the
other (but I also tested Firefox 3.5 and 3.0). For all I know Firefox
prioritizes redraws over javascript execution. However since I have
noticed that Firefox often appears to freeze up, while I have never
noticed any undue delays in Chromium, this benchmark does at least
give numbers with which to express my "feel" that Chromium is more
responsive. The precise numbers aren't that meaningfull, if I tried
the test another time I'd get slightly different results, but every
time I run this sort of test, Chrome comes out looking dramatically
better than Firefox.

[1] http://www.ucc.asn.au/~mccabedj/BrowserResponsivenessBenchmark.html
[2] http://flyingreptile.livejournal.com/179389.html
[3] http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

-- 
John C. McCabe-Dansted