up vote 0 down vote favorite
1
share [g+] share [fb]

After using Firefox since the days it was still called Phoenix, and doing that more or less exclusively. (I've been using Opera every now and then, when a new version came out), I've switched to Chromium about one and a half years ago.

Reasons were general design, speed and multi threading (which is one of the major speed gains, of course).

After I switched to Chromium, and didn't look back on Firefox, a friend kept using it, so I was well informed about the changes in its development. What caught my eye, was the new JägerMonkey JavaScript engine. It works well and all, but the feature that keeps me from switching back to Firefox, is that it's still (Firefox 4.0b7) single threaded!

I've compiled my version myself on Fedora 14, and I like the new interface etc, but speed wise, it's still lacking behind Chromium.

From searching the net, I found out that putting multi threading into Firefox is planned. But I don't see that happen in the current beta, so when is it coming? Or did I forget a switch while ./configure-ing the compile?

link|improve this question
79% accept rate
It's one of those things that's hard to just shove into a browser. This is one of the things that also caused some controversy with Snort vs Suricata. Suricata does multi-threading, but still doesn't perform as well as Snort according to some sources. There's a lot going on in thread management when you go multithreaded as well. The largest speed boost in chrome was the js engine not multithreading. If browsers didn't have to support plugins(think flash) I think this would have happened already. – aking1012 Nov 29 '10 at 7:10
According to what I've found on the net, JägerMonkey is faster now than V8, Yet I still find FF slower than Chromium, due to being single-threaded. – polemon Nov 29 '10 at 15:25
I don't think it's so difficult to make firefox multithreaded - google succeeded. To make it responsive and fast one could create one main thread for the UI and many threads to render the pages. Because the pages contain UI, the user input still should be procesed by the UI thread, but since the user can interact with only one tab at a time it's not a problem - the rendering thread for that tab will synchronize with the UI thread. Moreover the invisible of the tabs should use lower priority for their javascript execution, because they're not visible. If I were among the developers... – user64648 Jan 26 '11 at 18:30
2  
"If I were among the developers," you say... if it's "not so difficult" to make Firefox multithreaded, Mozilla would probably appreciate your contribution. Firefox is open source software! – nhinkle♦ Jan 26 '11 at 18:30
@user64648 It is difficult to 'safely' add 'multi-process support' if you do not do it from the beginning, like with Chrome. See here. – muntoo Nov 20 '11 at 9:09
feedback

closed as not constructive by akira, nhinkle♦, ChrisF, Sathya♦, Nifle Jan 26 '11 at 17:09

This question is not a good fit to our Q&A format. We expect answers to generally involve facts, references, or specific expertise; this question will likely solicit opinion, debate, arguments, polling, or extended discussion. See the FAQ for guidance on how to improve it.

Browse other questions tagged or ask your own question.