Recent Features
| |||||||||||||
In defense of FirefoxIn defense of FirefoxPosted May 29, 2008 9:17 UTC (Thu) by ekj (guest, #1524)Parent article: In defense of Firefox
Fine. But this is just an -example- of a -general- problem in FF. The fact that the UI is (or appears to be) single-threaded. I don't particularily -care- if some action that FF needs to perform takes 0.1 seconds, or 3 seconds. Offcourse I -prefer- if it takes 0.01s, but I can accept any if it's really nessecary. What irks me though, is that I've got 10 tabs open, and ALL of them, the ENTIRE user-interface freezes COMPLETELY because of something happening in ONE of the tabs. That is annoying and useless. There's no reason whatsoever that tab1 needs to not render or respond because tab2 is doing something or other.
(Log in to post comments)
In defense of Firefox Posted May 29, 2008 10:51 UTC (Thu) by Thue (subscriber, #14277) [Link] Agreed. It should really be multithreaded.
In defense of Firefox Posted May 29, 2008 15:09 UTC (Thu) by docwhat (subscriber, #40373) [Link] The threading isn't actually the whole of the problem. When fsync() is called on certain filesystems (ext3 without certain optimizations turned on is mentioned in the bug) it causes the whole desktop to freeze/slow as all the data is written to disk. fsync() in these filesystems is really just a call to sync(). :-( Ciao!
In defense of Firefox Posted May 29, 2008 15:50 UTC (Thu) by tjc (subscriber, #137) [Link] Some of the "freezes" in Firefox last 30 seconds or more, so I don't think it's the file system in all cases.
In defense of Firefox Posted May 29, 2008 18:48 UTC (Thu) by vonbrand (subscriber, #4458) [Link] For me, FF (on Fedora rawhide) freezes for good when accessing trac sites, or certain blogs (Groklaw, when trying to post a comment FF went off and didn't come back in an hour or so), and trying to comment on LWN got it frozen too.
In defense of Firefox Posted May 29, 2008 15:55 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] In my experience, UIs are always required to be single-threaded. The locking needed to make multi-threaded UIs work will tend to kill any speed advantage. Now some time-consuming operations maybe ought to be done asynchronously so the UI thread doesn't have to wait for them. But that's easier said than done. I suspect that the problem you're seeing (and which I recognise) is due to running Javascript in the UI thread. I don't know whether it's possible to avoid that, without introducing potential for deadlocks.
In defense of Firefox Posted May 29, 2008 16:46 UTC (Thu) by nix (subscriber, #2304) [Link] Well, yes, but if instead of single-threading you desynchronize the (event-driven) UI from the backend processing *and rendering* work, it can get fast again. (After all, what else is an X server?)
In defense of Firefox Posted May 29, 2008 16:47 UTC (Thu) by nix (subscriber, #2304) [Link] That is, of course, instead of *multi*-threading. :)
In defense of Firefox Posted May 30, 2008 7:19 UTC (Fri) by ekj (guest, #1524) [Link] The UI may need to be single-threaded. But handling the events need not be. Control could, and should, return to the UI-thread without waiting for the event to be finished handling. Just because tab a is currently in the process of repainting, there's no reason to -not- process new events coming in. Yeah, yeah, I know -why- FF is like this. But that doesn't change the fact that this particular aspect truly sucks.
In defense of Firefox Posted May 29, 2008 16:07 UTC (Thu) by intgr (subscriber, #39733) [Link] > There's no reason whatsoever that tab1 needs to not render or > respond because tab2 is doing something or other. The reason is the ancient design decision that the UI and behavior would be customizable through JavaScript extensions. As extensions are global (i.e. they can see and manipulate all of your tabs and UI elements), they need to live in a single interpreter. JavaScript has classically been a single-threaded language; making it multi-threaded now would create a lot of confusion and unexpected race conditions; most developers cannot even begin to imagine all the ways that, for example, the renderer and concurrent changes to a document's DOM could interact. Adding coarse-grained locking does not have much benefit: any interaction between concurrent threads would still likely cause one to wait for the other to yield a lock. On the other hand, with fine-grained locking, writing code to handle race conditions would make extensions and Firefox more complex and more error-prone. Furthermore, adding concurrent multithreading support to a high-level language is no easy task and has a significant performance impact on the interpreter alone -- as Perl, Python, Ruby, Smalltalk etc developers can confirm. Now, I'm just playing the devil's advocate and pointing out all the problems with this approach; clearly it is *possible* to rewrite Firefox as a multi-threaded browser, but it's a decision that has to be made with great precaution.
In defense of Firefox Posted May 29, 2008 18:13 UTC (Thu) by oak (guest, #2786) [Link] What would you lose if each Firefox window would be a separate process and only tabs within same window would be in the same process? At least moving a tab from one window to another would then be much harder, maybe even impossible if all the tab state needs to be moved too. Maybe windows-as-separate-processes could be a config option?
In defense of Firefox Posted May 29, 2008 18:48 UTC (Thu) by thoffman (subscriber, #3063) [Link] How about one thread per source domain? So if I have a bunch of windows and tabs open -- say, a Google Mail Compose window, plus the main Google Mail screen in a tab, then those two windows will be rendered by the same single thread, eliminating dangers of race conditions there. Meanwhile, in another tab, I have LWN open. It will be rendered by another thread. So, if Firefox's slow Javascript machine starts to suck wind in GMail, at least LWN will be nice and snappy on my multicore machine...
In defense of Firefox Posted May 29, 2008 19:53 UTC (Thu) by tjc (subscriber, #137) [Link] The reason is the ancient design decision that the UI and behavior would be customizable through JavaScript extensions. As extensions are global (i.e. they can see and manipulate all of your tabs and UI elements), they need to live in a single interpreter.That explains a lot! A repeatable example (at least for me) is linuxjournal.com, which freezes Firefox for about 15 seconds on my system.
In defense of Firefox Posted Jun 19, 2008 17:01 UTC (Thu) by tjc (subscriber, #137) [Link] This is no longer a good example -- the Linux Journal front page loads much faster than it did a few weeks ago, at least for me.
In defense of Firefox Posted Jun 5, 2008 5:30 UTC (Thu) by renox (subscriber, #23785) [Link] I agree that this is an important issue: I switched to Opera for this reason. And I doubt that FF3 will make me switch back as the 'one tab freeze the whole browser' issue will still probably be there.
In defense of Firefox Posted Jun 7, 2008 7:04 UTC (Sat) by muwlgr (guest, #35359) [Link] Konqueror gives better multitask experience as well. Otoh, its GUI does not use JavaScript.
|
|||||||||||||