If you run Firefox and look at the system resources, you will see the use of one processor go up until 100 percent when you load several pages at once. Most personal computers today have at least two processors, if not more, and not using them is a waste of your time. Instead of loading multiple pages one after the other as it is doing now, it might as well load them at the same time using different processors. While Chrome and Internet Explorer 8 support multi-threading (running on different processors), Firefox still lacks it in the official version. Support for multiple processors in Firefox is in the works and I tested a pre-release version of Firefox that loads different tabs in parallel. In this post I show some of the results I found.
The image illustrates performance increases of firefox version 3.5 versus versions 3 and 1.5. The TraceMonkey JavaScript engine in 3.5 makes javascript execute twice as fast as in Firefox 3 and 10 times faster than in Firefox 2. Image credit: Firefox web browser - under the hood.
Chrome and Internet Explorer run different pages independently. Rumors are running, Microsoft wants to replace Internet Explorer with a new browser, Gazelle, that runs independently not only all pages, but also, components on pages. Now what about Firefox?
While the official version of Firefox still runs on a single processor currently people at Mozilla foundation, which is responsible for the development of Firefox, are working to implement multicore support for Firefox. The project, called Electrolysis, is very ambitious and will bring a lot of value to Firefox users including security and speed. The first stage of development, what they call the sprint, is finished and developers around Benjamin Smedberg are now busy ironing out bugs. You can already download and build (compile) an early version for Linux or Windows and this is what I did.
This post is structured into three parts. First I report what I found with this pre-release version. The other parts are more technical. In the second part I report a detailed speed test results comparing it to another version of Firefox and Google Chrome. In the third part I'll show how to compile this version if you want to run it on your computer. You might want to skip the last two parts if you are not interested in technical details and don't feel up to the task of compiling Firefox yourself.
A Short Test of Electrolysis
In the sunspider javascript performance test, I found that the new build runs nearly 3 times as fast (1849.2 ms) as firefox 3.5.6pre (4554.4 ms), however chromium runs about 50 percent faster (1211.6 ms). I posted about Chrome installation in Ubuntu earlier and this test confirms my impression that Chrome has the edge on speed over Firefox (at least in interpretation of JavaScript). The downside with Chrome is however that it doesn't yet have all the functionality of Firefox.
I found out that Firefox pre-releases are titled minefield not only to deter the feeble. When I tried to load different pages at once, minefield crashed on me and a second attempt also failed. After restarting Firefox Shiretoko (version 3.5.6pre), the version I had installed previously, I noticed that all my preferences, extensions, and bookmarks had disappeared. Fortunately I use the XMarks add-on to synchronize my bookmarks, so quickly recovered my bookmarks. It took me about 10 minutes to re-install by add-ons and I might have to write my passwords out for some time, that's all I lost.
Well... what did I learn? Firefox is going to improve a lot in speed in upcoming versions. Chrome is now about 3 times faster than Firefox in JavaScript performance. What else? Don't run bleeding-edge pre-release versions. They may not work properly, can crash on you, and might delete your browser preferences.
Performance Test
Here come the details of the performance tests all performed on the same machine, my laptop.
- Firefox 3.5.6pre Electrolysis 3.7a1 Chrome 4.0.221.1 Total 4554.4ms +/- 2.0 % 1849.2ms +/- 4.5 % 1211.6ms +/- 3.9 3d 509.2ms +/- 4.3 % 268.0ms +/- 6.9 % 187.6ms +/- 16.1 cube 173.6ms +/- 9.9 % 97.6ms +/- 12.4 % 66.6ms +/- 25.2 morph 171.4ms +/- 9.2 % 56.8ms +/- 16.4 % 63.2ms +/- 26.0 raytrace 164.2ms +/- 6.3 % 113.6ms +/- 13.9 % 57.8ms +/- 16.1 access 676.2ms +/- 6.1 % 226.0ms +/- 6.5 % 99.2ms +/- 2.6 binary-trees 79.2ms +/- 12.2 % 53.0ms +/- 19.2 % 6.2ms +/- 9.0 fannkuch 262.0ms +/- 4.4 % 102.2ms +/- 16.1 % 36.4ms +/- 1.9 nbody 244.2ms +/- 11.1 % 42.6ms +/- 7.9 % 46.2ms +/- 6.1 nsieve 90.8ms +/- 13.5 % 28.2ms +/- 10.5 % 10.4ms +/- 6.1 bitops 535.2ms +/- 4.1 % 76.0ms +/- 5.8 % 95.4ms +/- 1.5 3bit-bits-in-byte 77.4ms +/- 17.6 % 3.2ms +/- 17.4 % 8.0ms +/- 0.0 bits-in-byte 113.2ms +/- 19.2 % 20.4ms +/- 23.8 % 20.8ms +/- 2.7 bitwise-and 208.4ms +/- 8.3 % 5.2ms +/- 10.7 % 28.8.4ms +/- 4.7 nsieve-bits 136.2ms +/- 12.6 % 47.2ms +/- 5.1 % 37.8ms +/- 1.5 controlflow 67.4ms +/- 27.7 % 52.0ms +/- 106.3 % 7.8ms +/- 17.5 recursive 67.4ms +/- 27.7 % 52.0ms +/- 106.3 % 7.8ms +/- 17.5 crypto 264.0ms +/- 11.2 % 117.0ms +/- 8.7 % 77.8ms +/- 7.7 aes 96.6ms +/- 16.4 % 63.0ms +/- 13.5 % 27.6ms +/- 21.3 md5 91.4ms +/- 6.8 % 33.2ms +/- 10.4 % 26.0ms +/- 3.4 sha1 76.0ms +/- 18.4 % 20.8ms +/- 26.5 % 24.2ms +/- 2.3 date 357.6ms +/- 7.5 % 265.0ms +/- 6.3 % 189.2ms +/- 7.8 format-tofte 160.6ms +/- 13.4 % 155.4ms +/- 7.3 % 87.4ms +/- 6.5 format-xparb 197.0ms +/- 3.7 % 109.6ms +/- 14.8 % 101.8ms +/- 14.6 math 531.6ms +/- 4.8 % 90.0ms +/- 4.0 % 124.0ms +/- 9.2 cordic 205.0ms +/- 5.9 % 31.2ms +/- 10.7 % 51.8ms +/- 22.9 partial-sums 229.4ms +/- 7.0 % 42.6ms +/- 4.4 % 50.8ms +/- 6.1 spectral-norm 97.2ms +/- 16.5 % 16.2ms +/- 8.4 % 21.4ms +/- 12.7 regexp 483.0ms +/- 8.2 % 153.0ms +/- 6.0 % 29.6ms +/- 2.3 dna 483.0ms +/- 8.2 % 153.0ms +/- 6.0 % 29.6ms +/- 2.3 string 1130.2ms +/- 3.6 % 602.2ms +/- 2.5 % 401.0ms +/- 5.4 base64 90.8ms +/- 16.4 % 18.0ms +/- 21.8 % 40.6ms +/- 4.6 fasta 224.4ms +/- 6.7 % 117.4ms +/- 11.4 % 73.4ms +/- 3,9 tagcloud 257.0ms +/- 11.3 % 186.0ms +/- 8.2 % 85.6ms +/- 5.5 unpack-code 407.6ms +/- 2.6 % 212.0ms +/- 12.8 % 118.8ms +/- 7.5 validate-input 150.4ms +/- 11.3 % 68.8ms +/- 11.3 % 82.6ms +/- 20.3
Compilation of Electrolysis
For the rest of this post I'll walk through an installation of Electrolysis on ubuntu. If you use a different Linux distributions or Windows, you can follow a similar path.
Download archive in gzip, zip, or bz2 formats, I downloaded gzip. The file took a while to download. Then you unpack the files, depending on the format you chose for download. I did tar -xvvf tip.tar.gz
There are pre-requisites for building of firefox. On linux, you need to install some packages (you'll also find instructions for other linux distributions and windows).
> sudo apt-get build-dep firefox
> sudo apt-get install mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libxt-dev libiw-dev mesa-common-dev
For building, you use GNU make and configure scripts (even on windows). Go to the top level directory of the code, cd electrolysis*.
Now configure your build options. It is recommended that you create a file, .mozconfig, where you put some options for building.
Create and edit a .mozconfig file. I inserted the following lines:
ac_add_options --enable-application=browser
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-optimize=-O2
ac_add_options --enable-optimize
ac_add_options --disable-tests
ac_add_options --disable-debug
Now we start compilation:
make -f client.mk build
Now you'll have a lot of time to think about the analogy between separating processes and the decomposition of water into oxygen and hydrogen.
Once finished, you find the build in dist/bin/. On Linux you execute the filefox binary, on windows you run firefox-bin. According to Mozilla, it is best to run it in a separate profile.
> cd dist/bin
> ./firefox -P JunkProfile
If you don't start with a new profile you might have to fix an error about xbl binding first.
My version of firefox shows 3.7a1. Go to firefox configuration typing about:config in location bar. With right click you insert a new boolean property dom.ipc.tabs.enabled and set it to true.
Hope you find the information in this article useful. Please feel free to leave feedback.
you have a nice blog with interesting info about computer science man!
wow..
It's very nice to hear such compliments, thanks!
Thanks for this info. I hadn't heard of the new version of Firefox coming, but I'm a Firefox fan and I'm looking forward to using it once they get the bugs ironed out.
@Jaya: I am also a big fan of firefox, but I can't deny that it's sometimes very slow. The tests that I present in my post give hope that the competition with chrome will bring us both feature-rich and faster browsers.
Your times on Firefox 3.5.6pre and Chrome 4.0.221.1 are identical. In the article, you stated that Chrome was slightly faster. Was there a cloning mistake in the table listing the times? If so, could you please fix that?
@Anonymous: Thanks a lot for pointing that out! I had lost the Chrome column somewhere while joining the table. The table should be correct now.
I now manually entered the Chrome column copying the data points from the original result which you can find here.
@Benjamin Auggarth: Thanks. That will make comparitive analysis easier. Were you using Ubuntu for the analysis or was it something else? Also, did you do any tweaks to the default optimizations the GCC profile uses?
@Anonymous: I was using ubuntu (9.04). For compilation of electrolysis I used gcc options as per the .mozconfig file shown in the post. Most important I think is the O2 switch. I don't know if the --enable-optimize mozconfig options has any additional effect.
I don't know how Firefox 3.5.6pre was compiled. I am now downloading source of Firefox in order to compile with exactly the same options that I used for electrolysis. For the record: to download the firefox source code base go to developer.mozilla.org.
Ok, finally I found the source code for Firefox 3.5.6. It's at a mozilla ftp repository.
I compiled Firefox 3.5.6 with the same compiler options as before used for compiling Electrolysis. I redid the test with the recompiled 3.5.6. You can find results here.
I think they do not significantly differ from the results I found without recompiling. The total is a 5185.8ms +/- 1.9% which is much slower than Chrome or Electrolysis, so I think it's warranted to say that the differences in speed between 3.5.6 and Electrolysis came not from compiler optimization but from differences in Firefox.
From the article:
"multi-threading (running on different processors)"
That's not the definition of multi-threading. That's multi-processing. Multi-threading is running multiple threads of execution in parallel on a single core via time-slicing.
It's fantastic that you're excited about the early 3.7 development work, but there are a few issues with your post that I think should be clarified...
1) There's no need to compile your own 3.7pre build -- we make nightly builds available (see http://nightly.mozilla.org/). It helps if people use these, because these builds keep themselves up-to-date automatically, and will report crash data to us (opt-in, natch) so we can catch problems early.
2) Doing your own compile for performance comparisons usually isn't a good idea, we've already spent a lot of time tweaking how things are built (eg https://bugzilla.mozilla.org/show_bug.cgi?id=409803). Your inclusion of "--enable-optimize=-O2" has, in fact, likely made your build slower than the official builds! If you're really keen on doing your own build, the steps at https://developer.mozilla.org/En/Simple_build are really all that's needed. We don't recommend people put extra stuff in their mozconfig unless there's a very specific reason for it.
3) The Electrolysis work to date has largely focused on backend work, mobile (Fennec) work, and getting plugins (eg Flash) running in a separate process. The work on, err, electrolyzing Firefox itself is just ramping up. So, unfortunately you're not really testing Electrolysis yet.
4) Electrolysis itself won't really help with things like Sunspider -- speedups there are due to improvements in the JS engine itself. Electrolysis is more about stability and security, and performance when running multiple tasks on a multicore box.
5) As other comments noted, multiprocess != multithreaded. Firefox is already multithreaded (eg, top reports 18 threads in my particular case), and web sites can already make use of that with web workers (see http://hacks.mozilla.org/2009/07/working-smarter-not-harder/).
In any case, your basic point is correct. There's a lot of exciting things in the Firefox pipeline, and 2010 is going to be a very awesome year. :-)
This is wrong (the article is correct).
A process is a block of code (i.e. an application) that has it's own memory area, stack and other computer resources. This means that if a process crashes, it will not affect another process. In the case of Chrome, Chrome runs each tab in it's own process, so if a tab crashes it will not crash the Chrome browser itself.
A thread shares some of the resources for a process, and is usually cheaper to create. A process will always have at least one (main) thread. A thread is a block of code to be executed. The Operating System will assign different threads to different processors (or the same processor) to be run.
Time slicing is one mechanism that an Operating System can use to schedule different threads to be executed, but is not the only one.
PROTIP:
Always backup your profile folder before fiddling with test versions. Then if something goes wrong, you simply re-install the stable version, copy your profile folder back, and everything (bookmarks, plugins, preferences, etc) is restored.
"While Chrome and Internet Explorer 8 support multi-threading (running on different processors), Firefox still lacks it in the official version."
Firefox is multi-threaded and has been for a while, and anonymous above does a good job of pointing out the difference between the terms multi-thread and multi-process.
Thanks a lot for all the comments. Your corrections and pointers are appreciated.
I should have been more clear about the terms multi-thread and multi-process. I was trying to make the introduction understandable to a general audience and it ended up too sloppy. I put the links to wikipedia article here for the record: thread, and process.
@Nick Nethercote: The 3.5.6 is a standard build. I didn't make any changes.
Great article and an interesting read, thanks very much.
I download the latest nightly build every day (and report any bugs I find) but I wasn't aware of the performance increases, very encouraging.
A side note, you can also enable electrolosis on the latest trunk builds by changing the 'dom.ipc.plugins.enabled' value to 'true' in 'about:config'.
I have also noticed an option 'dom.ipc.tabs.enabled' but I hear that its not implemented and not even ready for testing yet.
I've been running nightly builds of Minefield 3.7a1pre (Mozilla/5.0 (X11; U; Linux x86_64; sv-SE; rv:1.9.3a1pre) Gecko/20100106 Ubuntu/9.10 (karmic) Minefield/3.7a1pre GTB7.0) as my main browser on a HP Pavilion d4595se, AMD Athlon 64 X2 5000+ Dual Core box for quite some time, and have found it snappier than both 3.5.x and 3.6.bx versions, but not quite as snappy as Chromium (no objective tests, just subjective impressions). This, however, is the first time I've heard of «electrolysis» - have I been speaking prose without being aware of it ? Furthermore, I note that the value of my «dom.ipc.plugins.enabled» Boolean is set to «false» by default ; what would the effects of changing it to «true» be, if any ?...
Henri
Why not try 3.6 RC1 too http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6rc1-candidates/build1/
Thanks for this post. I compiled FF for Windows last night and it runs quite well. I open a large number of tabs simultaneously. (o;
Nick Neithercote is right. The differences you have between Fx 3.5 and Minefield 3.7 are much too high and indicates that your Fx 3.5 doesn't have its JIT compiler enable.
This can be the case if you use a 64-bit build on Linux. There wasn't a JIT-compiler for 64-bit in Fx 3.5. It was added for Fx 3.6.
IPC stands for inter-process communication. As I understand it, with both properties, dom.ipc.plugins.enabled and dom.ipc.tabs.enabled, you have options to enable parallelization of both plugins or tabs. As Nicholas Furgiuele points out, enabling any of the properties will electrolyze your Firefox (if it's a newer version).
@Anonymous: I use a 64bit system. If the JIT compiler for 64bits was added as you say in 3.6 and for 32bits earlier than this could mean that at least part of differences between 3.5.6 and 3.7 would apply only for 64bit systems. However I am not sure it is true what you say. I found in this post by Andreas Gal that the tracemonkey jit compiler was in the Firefox main trunk since August 2008 and also worked for 64bits.
Benjamin, JIT compiler for 64-bits were turned on on September 15th, 2009 (on the branch that lead to Fx 3.6).
Prior to this only confidential test builds (aka Tracemonkey builds) could have JIT on 64-bits. But no official build, neither by Mozilla, neither by the different Linux publishers.
The proof: http://www.bailopan.net/blog/?p=595
So the upcoming Fx 3.6 (now at the RC stage) will be the first released version of Firefox to support JIT on x64.
Concerning dom.ipc.tabs.enabled, it does nothing on a trunk build, and will likely be much buggy on a electrolysis-branch build. plugins.enabled does work though (on Windows and Linux, not Mac). They are discussion if they want to port it back to a 3.6.x release or way for a mid-year 3.7 release. This is not yet decided, but the 3.6.x release of plugin electrolysis has the lead.
Finally concerning the better results in Sunspider, basically (and informally) the results are:
Fx 3.5 -> Fx 3.6: -15% (and much more if you are using a 64-bits build as JIT is now working)
Fx 3.6 -> current trunk nightly: -5% (a little better if you take a tracemonkey nightly).
Thanks for the feedback again. I conclude from the discussion that the javascript execution improved a lot with the introduction of the new JIT compiler, which was in version 3.6 on 64bit platforms.
I just found a newer benchmark of HTML5 Canvas Javascript performance that again shows big differences in rendering between different browsers and I thought it worth mentioning here. Freeciv developers compared Safari on Windows, IE 8 on Windows, Firefox 3, Firefox 3.0.15 on Linux, Firefox versions 3.6 and Firefox 3.7a1 on Windows, and Chrome 3.0 on linux, and Chrome 4.04 on Windows. They found that internet explorer is slowest by a great margin, Firefox version 3.0.15, next slowest, has about double the speed. Next come Firefox 3.6 and Firefox 3.7a1, which are about the same level and bring a great speed-up with respect to 3.0.15. Safari nearly doubles their speed. Chrome versions 3.0 and 4.0.4 are fastest and in turn much faster than Safari.
Subscribe to replies to this post
This conversation is missing your voice. Your feedback is appreciated.
Post a Comment
You can use some HTML tags, such as <b>, <i>, <a>
You can follow the discussion of this post by subscribing.
You are free to include information from this article on your own site if you provide a backlink. You can use the following markup: