“IonMonkey is the name of Mozilla’s new JavaScript JIT compiler, which aims to enable many new optimizations in the SpiderMonkey JavaScript engine. InfoQ had a small Q&A with Lead Developer David Anderson, about this new development that could bring significant improvements in products that use the SpiderMonkey engine like Firefox, Thunderbird, Adobe Acrobat, MongoDB and more.”
Vaguely related:
http://digitizor.com/2011/04/30/ff6-fast-less-sluggish/
Synopsis:
The only grumble is that these optimizations won’t be released until Firefox 6 which is scheduled for later this year.
Weird… In my experience, the Linux builds have always been the fastest by far in everyday use.
It is entirely possible that your Linux distribution (as opposed to Mozilla labs) did not have any issues with its build system.
Edited 2011-05-03 05:32 UTC
If it’s Gentoo, for example, the build process of Firefox is already what Mozilla is going to do, i.e. the optimizations per se have taken place as soon as you typed “emerge firefox”
No, Gentoo dont do profile guided optimization, if it does, tell me how to enable it.
I don’t know about Gentoo, but on Arch (which I use) I’ve been using PGO enabled builds for quite some time (AUR package), and yes there’s certainly a difference in performance. However on the Linux PGO builds that I’ve done on Arch, Mozilla defaulted to -Os (and I remember reading that they did this because they got better performance with -Os than say -O3) but from what I read recently it seems as though they had problems compiling with -O3 using PGO and that this has recently been solved.
Firefox on Linux is way faster than Firefox on XP for me, but that is not exactly a far comparison since my XP installation runs in 32-bit while my Arch installation runs 64-bit, still it’s certainly not slow on XP by any means (and as such obviously not on Linux either).
So if this new PGO build fix increases Firefox performance further on Linux then all the better.
nah linux builds always been slower on heavy pages
i’m not sure thats just “gcc optimizations” to be honest
it’s more about the underlaying toolkits and so on
chrome/mium pack a ton of its own libraries to circunvent that i believe
ff uses native
It is not only “gcc optimizations”, Firefox on Windows has been a bit faster than Firefox on Linux because of “Profile Guided Optimisation”.
http://en.wikipedia.org/wiki/Profile-guided_optimization
This has not worked up until now in the versions of gcc that Mozilla labs was using (although other Linux projects have been able to use it).
Nope.
Nope. You can check this by installing Firefox from your distribution’s repository using apt-get or equivalent … it doesn’t pull in any other dependencies. You can also confirm it by downloading a binary .tar.bz2 package … unpack it and it just runs essentially without having to make sure any native packages are already installed.
Edited 2011-05-03 10:30 UTC
That isn’t true, just take a clean install of let’s say 64-bit Ubuntu and download a 32-bit version of Firefox from the site. You can see a lot of broken stuff, not in the least the fonts and GTK-handling in Firefox.
I did, and you are wrong. On my system firefox4 depends on xulrunner, which in turn depends on:
alsa-lib
dbus-glib
gcc-libs
gtk2
hunspell
libevent
libidl2
libnotify
libxrender
libxt
mime-types
mozilla-common
nss
sqlite3>=3.7.4
startup-notification
The gtk2 dependency in turn pulls in:
atk
cairo
gnutls
gtk-update-icon-cache
heimdal
libcups
libxcomposite
libxcursor
libxdamage
libxi
libxinerama
libxrandr
pango
shared-mime-info
So while firefox itself might depend only on xulrunner, xulrunner pulls in quite a few dependencies. Granted, most of this stuff is already present on a typical desktop setup, so it might not seem like any dependencies are needed when you install firefox since most dependencies would already be installed. This is especially true if your distro does not split up the xulrunner and firefox packages. Nonetheless, the claim that firefox does not need any external libraries is false.
Just for comparison purposes, the chromium dependency list is not exactly small either:
alsa-lib
bzip2
dbus-glib
desktop-file-utils
gtk2
hicolor-icon-theme
libevent
libxss
libxtst
nss
ttf-dejavu
xdg-utils
This is the point. All of the things that Firefox uses (beyond the contents of the Firefox tarball) are already part of the default desktop installation. You can tell this when you install Firefox on a typical desktop … everything except Firefox itself is already there just in order to have a desktop.
This is just as true for Linux as it is for Windows, there is no difference.
Because there is no difference, these external elements cannot account for Linux vs Windows speed differences in Firefox which are not observed in other programs which also use these desktop libraries.
Edited 2011-05-03 23:16 UTC
You’re right, but for the wrong reasons. Using external dependencies does not significantly slow down a binary much. Chrome/Chromium originally did just hack parts of other libraries into itself for no good reason, other than laziness in working with upstream. Other people such as Fedora’s Tom Callaway aka spot have been working with Google and the projects behind the bundled libraries to get chromium to use more native libraries.
This is old and not the current situation, but this was accurate at the time:
http://spot.livejournal.com/312320.html
This is the current status of that effort:
http://code.google.com/p/chromium/issues/detail?id=28287
Edited 2011-05-04 04:31 UTC
I’m sure the feature set of Firefox 5 is almost set