Slashdot Mirror

← Back to Stories (view on slashdot.org)

Testing a Pre-Release, Parallel Firefox

Posted by kdawson on from the use-what-ya-got dept.

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).

26 of 278 comments (clear)

  1. Good thing by Darkness404 · · Score: 3, Insightful

    This is a good thing. Firefox desperately needs to modernize. About the only killer feature left in Firefox is customization. Other browsers have already caught up to Firefox in speed, features, and standards support.

    --
    Taxation is legalized theft, no more, no less.
    1. Re:Good thing by Qubit · · Score: 5, Insightful

      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.

      --

      coding is life /* the rest is */
    2. Re:Good thing by Darkness404 · · Score: 4, Insightful

      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.

      --
      Taxation is legalized theft, no more, no less.
    3. Re:Good thing by Anonymous Coward · · Score: 3, Funny

      Right! I mean, apart from cross platform stability and the add-ons and the themes and the ability to customize everything and the adblock, what have the Firefoxes ever done for us, eh? Splitters!

    4. Re:Good thing by SanityInAnarchy · · Score: 3, Interesting

      If it had a more stable Linux version

      What? The beta is pretty rock solid for me. There's one annoying, persistent bug in HTML5, which I haven't bothered to get annoyed about since I don't really see enough HTML5 video to care.

      But until fairly recently, Flash was crashing a lot for me. That meant I ran Konqueror a lot, because crashing an entire window full of tabs is still better than crashing all windows full of tabs.

      I ran the Chrome nightly builds until there was a stable beta. There were occasional and annoying bugs, but I would often go for weeks without problems. Worst case, a tab crashes, you hit refresh -- but days and weeks pass between those. Honestly, the released version of Firefox was less stable overall, at the time.

      had all the addons/themes

      I'm not sure how good it's going to be, or how likely it is to work at all, but I did hear people proposing ways for Chrome to run Firefox extensions. However, it does have plenty of its own.

      along with the ability to customize absolutely everything

      I'll definitely give you that. There are things I've seen Firefox extensions do that Chrome extensions can't touch, yet. But that's actually a nice tradeoff -- Chrome extensions are somewhat limited, but it means that if you try to install, say, the YouTube downloader, it'll only touch your data on Youtube.com, it'll say so, and Chrome will enforce it.

      Still, I think it's possible to have our cake and eat it, too.

      the fact that its available in Ubuntu without needing extra repos

      Why is this a blocker?

      I guess, from a privacy/security standpoint, I could see an argument, but from sheer usability, you can actually point and click on a deb to both download Chrome and automagically enable the extra repos.

      --
      Don't thank God, thank a doctor!
    5. Re:Good thing by Trepidity · · Score: 4, Interesting

      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.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    6. Re:Good thing by hairyfeet · · Score: 3, Interesting

      I'm sorry, but that is nothing at all like Noscript, that is just...well a really bad hack. If I have a site where there are multiple scripts (which is pretty much every site now) can I run only ONE script, while blocking the rest? in FF yes, In Opera? Not a chance in hell. It is all or nothing, which frankly makes it pretty worthless. if you are gonna trust everything on one site to run, you might as well trust all, because even a trusted site can get hacked. With FF and Noscript ONLY the code I approve of runs, period. I don't care if I have been to that site one times or 100, I decide what goes and what doesn't.

      So I'm sorry, but while Presto is a nice browser engine FF wins on control. I would rather a page take a second or two longer to load and have complete control over what is allowed to run than use Opera's risky "all or nothing" approach. I'm afraid like adblocking in Opera it is a kludge, whereas with Firefox and their excellent extensions support I can customize my browser my way and have complete control. I have to agree with the other posters the Ff extensions system is what keeps me on Firefox. It is powerful enough that you can find an extension to do just about anything, while still being easy enough even my dad can use them. FF FTW.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    7. Re:Good thing by msclrhd · · Score: 4, 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.

    8. Re:Good thing by Trepidity · · Score: 3, Insightful

      That's true, but Firefox will at least still run on platforms it doesn't have a native JS compiler for, presumably by falling back to the interpreter. Chrome just doesn't exist for non-x86/arm platforms.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
  2. Thread != Process by kiltyj · · Score: 5, Informative

    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.

    1. Re:Thread != Process by BadAnalogyGuy · · Score: 3, Interesting

      There is no reason FF couldn't use separate threads to handle the threading of separate tabs. As it is, if any tab locks up, then the whole set of tabs gets stuck. Whether you use a process to separate each tab or you simulate it with threads, the difference is merely architectural.

      The shared memory and object resources is the bottleneck with threads, but there is no reason why a single process couldn't render separate tabs completely separately.

    2. Re:Thread != Process by Magic5Ball · · Score: 5, Interesting

      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.)

      --
      There are 1.1... kinds of people.
    3. Re:Thread != Process by fm6 · · Score: 5, Insightful

      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!).

    4. Re:Thread != Process by EvanED · · Score: 4, 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.

      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

  3. Tabbed processes would be better by BadAnalogyGuy · · Score: 5, Insightful

    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.

    1. Re:Tabbed processes would be better by Gothmolly · · Score: 3, Funny

      Stop surfing porn at work then.

      --
      I want to delete my account but Slashdot doesn't allow it.
    2. Re:Tabbed processes would be better by BZ · · Score: 4, 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...

  4. Summary is wrong! by A12m0v · · Score: 5, Insightful

    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.

    --
    GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
  5. FireFox is great, but... by NormAtHome · · Score: 3, Interesting

    Don't get me wrong, I love FireFox and it's my preferred browser but I do feel like it's falling behind in a lack of ability to take advantage of certain hardware and software advances.

    First as noted, FireFox does not really take advantage of multiple Cpu core's 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 and 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.

    1. Re:FireFox is great, but... by Anonymous Coward · · Score: 3, Informative

      Fennec is Firefox's version of a mobile browser, with finger/pointer panning.

    2. Re:FireFox is great, but... by Hurricane78 · · Score: 4, 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. :)

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
  6. The first sentence is wrong by parallel_prankster · · Score: 5, Interesting

    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 ?

  7. ummm... by buddyglass · · Score: 3, Insightful

    Process-per-tab shouldn't speed up Javascript unless you're doing something else in a second tab that's hogging CPU. Most likely the Javascript performance gains came simply from the fact that he was using a 3.7 branch of the code. Which is kind of sad, considering bleeding-edge Firefox still lags behind Chrome by a considerable margin.

    1. Re:ummm... by BZ · · Score: 4, 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.

  8. Re:Processors do not matter... by Pausanias · · 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.

  9. Re:Processors do not matter... by Z80xxc! · · Score: 4, Informative

    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.