Testing a Pre-Release, Parallel Firefox 278
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).
Thread != Process (Score:5, Informative)
Firefox, in its official version, still lacks support for multi-threading
Firefox certainly supports multi-threading. A thread [wikipedia.org] is not the same thing as a process [wikipedia.org].
Re:FireFox is great, but... (Score:3, Informative)
Fennec [mozilla.org] is Firefox's version of a mobile browser, with finger/pointer panning.
Re:FireFox is great, but... (Score:3, Informative)
and there's no official 64 bit version. I've read that the developers opinion is that why have a 64 bit version if the most necessary plugin, flash is not available in a 64 bit version so why bother. But Sun does make a 64 bit JRE and that's half the battle
Flash is used on just about every site out there. Java isn't. About the -only- issue I've had with Java not being installed was that I had to use the simple uploader to upload pictures on Facebook. I haven't had a Java plugin installed in 2-3 years and haven't experienced any loss due to it. However, the lack of Flash would make most sites unusable that the average person goes to A) YouTube B) Flash game sites C) Flash cartoon sites like Homestar Runner D) A -lot- of sites have Flash for navigation.
I honestly believe that if a 64 bit official version of FireFox were released that would spur Adobe to jump on the band wagon and produce a 64 bit Flash plugin.
Who would use it? I still use a 32 bit OS because I see no need in switching to a 64 bit OS. I'm currently running Ubuntu 32 bit on a 64 bit CPU, I really don't see the need in changing. Really, I don't expect to upgrade my RAM past 2 GB anytime soon and there isn't any software that is 64 bit only, but a lot of software is 32 bit only.
For Windows its even worse, why would someone pay extra for an OS? If its pre-installed people may use it, but most of the time even Windows 7 is shipping in 32 bit versions. Unless you want a huge amount of RAM, theres little need to get a 64 bit OS.
Re:Tabbed processes would be better (Score:5, Informative)
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...
Re:ummm... (Score:5, Informative)
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:ummm... (Score:3, Informative)
But yes, you're right that the multi-process parts of electrolysis (which this guy didn't enable and hence wasn't testing) have nothing to do with JS performance.
Re:Processors do not matter... (Score:5, Informative)
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... (Score:5, Informative)
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... (Score:5, Informative)
Re:Thread != Process (Score:3, Informative)
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.
Re:Thread != Process (Score:4, Informative)
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:
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
Re:Good thing (Score:5, Informative)
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.
Re:Good thing (Score:3, Informative)
https://chrome.google.com/extensions/detail/cfhdojbkjhnklbpkdaibdccddilifddb [google.com]
AdThwart. AdBlock for Chrome, essentially. Works fine for me.
Re:TLDR version (Score:1, Informative)
I don't know about X but you're half wrong about Java AWT/Swing. A Java program launches with a main thread. If you create an AWT component (which includes any Swing component) then it spawns an AWT thread to do event dispatch and (under X at least) a thread which handles the interrupts and pushes events at the dispatch thread. In certain circumstances, such as a certain blocking call in the API which displays a modal dialog and waits for it to be closed, it creates a second AWT thread which takes over event dispatch, as otherwise the modal dialog would be frozen and the application would have be deadlocked.
Re:When has threads ever simplified anything? (Score:3, Informative)
They are easier in other programming languages (Java, Python)
Re:Good thing (Score:2, Informative)
They sort of work for me. They don't block ads but hide them after the fact. This causes noticeably slower browsing on some sites where the ad servers are slow or ad content bloated.