Testing a Pre-Release, Parallel Firefox

Firefox, in its official version, still lacks support for multi-threading (running on different processors), though Chrome and Internet Explorer 8 both have this feature. A Firefox project called Electrolysis is underway to close this gap. A blog author tested a pre-release version of Firefox that loads different tabs in parallel, and he chronicles his findings, including a huge speedup in Javascript vs. Firefox version 3.5 (though the pre-release still lags Chrome in many of the tests).

Comments

Thread != Process

[kiltyj]

Firefox, in its official version, still lacks support for multi-threading

Firefox certainly supports multi-threading. A thread is not the same thing as a process.

Re:Thread != Process

[Magic5Ball]

Read bug 40848 for the list of technical issues. Amongst other things, document windows may display and communicate with each other, or refer to each other, which leads to race conditions, etc.

(The process documented in 40848 also explains why this idea has taken 9.5 years and some skunkworks outside/despite the open development process to get this feature to this point.)

Re:Thread != Process

[fm6]

The writer's mistake is more basic than just conflating threads and processes. You left out the parenthesis:

still lacks support for multi-threading (running on different processors)

Which not only conflates cores and processors, but also suggests that multithreading isn't useful if you don't have multiple cores/processors.

When I was writing the concurrency chapter in the Java Tutorial, the experts would give me a very hard time if I allowed even a vague suggestion that this was true. The fact is, threads are extremely useful even if you only have one core to work with. For example, any well-written GUI program will not handle user interaction in the same thread with other functions; if it did, the GUI would freeze every time the program were waiting on something.

Multithreading is a big topic these days because everybody wants to maximize their utilization of all these n-core processors. But it's not a new topic.

This mistake seems to be very common. Which leaves me confused as to what's new here. It's not parallel downloading of files — Mozilla/Firefox has always done that. A more robust parallelism mechanism? Or maybe they're copying Chrome and giving each tab its own process (not thread!).

Re:Thread != Process

[EvanED]

I might have this wrong, but I believe event-driven programs are, by their nature, multithreaded. This might not be obvious if you write a program by plugging event handlers into an event framework, such as MFC. But multithreading is still going on in the framework.

You're wrong. Let's look at the MFC example in more detail. I'll talk about what Windows does quite a bit, but the gist of how it works I think is common to virtually all GUI systems (including Java Swing and X, though don't count me as an authority).

Here's a sequence of steps to follow to illustrate:

• Start Visual Studio (I used 2008 Professional)
• Create a new "MFC Application" project with default settings (multiple documents, doc/view architecture, MFC standard, MFC in shared DLL, no compound doc support, no DB support)
• Compile and run (I started with ctrl-F5 rather than debug)
• Open Task Manager, ensure that the Threads column is active
• Find your test program and note it has 1 thread

MFC is a relatively thin wrapper around the Windows API. The way that you program using the raw Windows API is as follows. The startup procedure (WinMain I believe) creates a new window and displays it to the user. As part of the creation of this window you pass a function pointer that is the address of the callback function that should respond to "messages" that Windows sends your program.

I don't recall the exact signature of the callback function, but it takes four parameters. The first is a pointer to the window that receives the message (so you can use the same procedure for multiple windows). The second is an enum that's the type of the message -- e.g. a button press, mouse click, resize, etc. -- and the third and fourth are message-specific information (e.g. what button was pressed or what the new size is).

Finally, what WinMain does is start the message loop. This is essentially an infinite loop which retrieves then dispatches the next message. (This is often hidden in a "run" function on similar by frameworks such as MFC or Qt.)

So let's consider the path of an event that occurs. Say the user presses 'e'. Windows determines which window is supposed to be notified of the key press, in this case whatever has focus. (There are parenting relationships too, but I won't get into that.) It translates that event into a message it will pass the program -- WM_KEYDOWN. (There's also a WM_KEYUP message.) Windows adds the WM_KEYDOWN message to the application's message queue.

At some point the message loop in WinMain will run (hopefully -- if not, I believe this is exactly what Windows means when it says a program isn't responding). It will retrieve the WM_KEYDOWN message then dispatch it. Retrieving it consists of removing it from the message queue, and dispatching it consists of calling the callback function. (Both of these are hidden from view behind API calls GetMessage and DispatchMessage.)

Windows figures out what callback function needs to be called, then calls it with that window handle, the WM_KEYDOWN message, and information about what key was pressed. The callback function does its thing, then returns. Returning transfers control back to Windows (inside DispatchMessage) which then transfers control back to the application in the message loop, and the program then retrieves and dispatches the next message, if available. (If not, it blocks until one is available.)

The point to notice in this process is that at no point is another thread created. When Windows originally notices an event, it simply places a message into the application's message queue. When the application retrieves and dispatches a message, that is done with simple control transfers within that thread.

While it's true that this sort of programming doesn't quite look like what you get from MFC, .Net, Java Swing, Qt, etc., you'll find a lot of people out there who will say that it's still event-driven programming. And more to the point, if you a

Tabbed processes would be better

[BadAnalogyGuy]

Multithreading still relies on a single point of failure - the shared memory space.

By doing what Chrome did, and breaking each tab instance into its own process, any single tab can crash/hang without affecting any other page.

I know when I load an MPG video that it sometimes hangs the browser, and I can't do anything (close/minimize/switch away) while the media player is being loaded. This sometimes causes me stress.

Re:Tabbed processes would be better

[BZ]

In fact, Electrolysis aims to have tabs in a separate process from the browser UI as a first cut, then work on separate tabs in separate processes. That's not enabled by default, though, so the guy who wrote this blog post wasn't testing it...

Summary is wrong!

[A12m0v]

Firefox does support multithreading, what it doesn't support is multiprocessing. Firefox runs as a single process, whereas Chrome has a separate process for every site, plugin and extension.

Re:Good thing

[Qubit]

Other browsers have already caught up to Firefox in speed, features, and standards support.

Many mainstream browsers are speedy, or at least speedy enough, but Firefox does offer a unique mix of features:

Ogg Theora/Vorbis: Currently supported by Firefox, Chrome, Opera
FOSS: Firefox, Chrome (just Chromium?)
Cross-Platform on Win, Mac, GNU/Linux: Firefox, Chrome (maybe just beta?), Opera

For me, both Firefox and Chrom{e|ium} look like good contenders. I've had good experiences with Mozilla products for quite some time, so I'll probably continue with Firefox.

The first sentence is wrong

[parallel_prankster]

On so many levels !! first of all - The title of the Electrolysis page clearly mentions using multiple processes - where the heck did anyone mention multi-threading? Secondly - multi-threading is not the same as running on different processors. You can potentially split a program into user level threads just to simplify code. Third - firefox already supports multi-threading. The only problem is that threads are still connected to the same PID and killing that in windows/linux/mac will kill all threads along with it. The original article states they are starting from a chromium base. That may be the reason for speedup in Java scripts test ?

Re:Good thing

[Darkness404]

And really, Chrome is -the- browser to beat right now. If it had a more stable Linux version and had all the addons/themes along with the ability to customize absolutely everything, chances are most Linux distros would ship with it over Firefox.

Yeah, Firefox and Chrome may be the only two competitors with some features, but compared to others, Firefox just can't compete. Things like supporting multi-threading, tab isolation, plugin isolation, JavaScript execution speed, and general UI responsiveness are all things that Firefox really lacks. Right now, the ability to customize and the fact that its available in Ubuntu without needing extra repos, are about the only things that are keeping me from using Chrome full time.

Re:ummm...

[BZ]

Lags behind Chrome on a particular benchmark (Sunspider). Ignoring for the moment the Sunspider tests that are purposefully slower in SpiderMonkey than in other JS engines (by using extension features that only SpiderMonkey implements and that slow the test down if implemented), that leaves the question of how relevant Sunspider is.

In my testing, Chrome is anywhere from 4x faster to 4x slower than Firefox on various JavaScript/DOM/canvas tasks. It really depends on the task, as expected: if nothing else different jit heuristics will lead to better or worse performance on the same code even if all else is identical.

Re:Processors do not matter...

[Pausanias]

You do realize that your Prescott Pentium IV is more power hungry than Intel's current faster offerings, right? Perhaps you should buy an AMD if you despise intel and would like to be greener.

Re:FireFox is great, but...

[Hurricane78]

Uuum, sorry? I use 64 bit Flash on Linux right now. Yes, from Adobe.
They still call it alpha, but apart from it sometimes hanging the browser for a minute at start, but then working... and a bit of memory leaking... it is no different from the r32 bin Windows release version.
Also, video playback is much faster with it.

Also, no 64 plug-in is a lousy excuse. As we use Flash on 64 bit systems trough multilib/“emulation” since forever.
Oh, and since my Firefox is self-compiled, I’m pretty sure it also is 64 bit. :)

Re:Processors do not matter...

[Z80xxc!]

Do realize that your P4 consumes a lot more power than a previous-generation (65nm) Core 2 Duo, and in some tests even more than a Core 2 Extreme. Modern 45nm chips use even less power. So really, you're dumping money down the power/heat drain by not using a newer processor. Even if you don't need the speed, it makes a difference in terms of the electric bills. Your point about electricity is completely and entirely invalid.

Re:Good thing

[Trepidity]

This is admittedly not an issue for a ton of people, but Chrome/Chromium is less architecture-portable as well, since instead of being all C/C++ or some other portable language like most browsers, its JavaScript engine directly emits native code.

It can currently do x86 and ARM, which covers almost everyone, but does mean that it can't run it on, for example, PPC macs, so I can't use it on my PowerBook, which is actually the machine that I'd most appreciate a faster browser on.

Re:Good thing

[msclrhd]

There is nothing that mandates that you must have tons of addons installed. Yes, they are available and some are useful, but they are not required.

Firefox startup time being slow (and yes, the more addons you have, the slower it will be) falls into the following areas:
    * disk I/O (which is not dependent on CPU speed);
    * element reflow analysis being called a large number of times (this is a fancy way of saying where everything is positioned on the page - which, yes, does include the UI);
    * element reflow analysis takes a long time each time it is performed;
    * javascript performance.

The Firefox team are working on, investigating and making improvements to these areas.