Firefox Still Working Towards Multi-Process Support

[Marc Driftmeyer]

Firefox doesn?t crash.

Yes it does. On Linux the flash-plugin being taxed heavily will bring it down without much hesitation.

[mrugiero]

Actually, it does. I've had it crash on me just from having 3 flash-heavy tabs opened. I don't recall getting a crash in the last release, but there have been a couple times I get some severe slowdown. While this isn't necessarily firefox's fault (opera had stability problems with flash too), firefox still crashes in the end.

What firefox really needs to do is separate each tab as it's own process, much like chrome. I don't want the entire browser failing on me because 1 tab fails. The irony is chrome has a newer and more stable version of flash.

Before a given release (I don't recall the number), the flash plugin ran within the main process, which lead to awfully common crashes. I didn't mentioned it because it was a LONG LONG time ago (64 bits precision integer time ago (?)). It was both Flash (for being horribly unstable, at least and that time) and Firefox (for running it within the main process, although it was the common practice for some time) fault.

I don't think a process per tab is reasonable, I think that would eat too much memory for the extra processes (at first I thought it would also involve too much overhead for the message passing, but as long as tabs don't interact between them, the amount of messaging should remain the same as having all the tabs in a single separate process), but some groups. I don't know, something like four tabs per process or something like this, so you don't lose all of them when one fails badly, but you don't get that much memory overhead.

[schmidtbag]

Before a given release (I don't recall the number), the flash plugin ran within the main process, which lead to awfully common crashes. I didn't mentioned it because it was a LONG LONG time ago (64 bits precision integer time ago (?)). It was both Flash (for being horribly unstable, at least and that time) and Firefox (for running it within the main process, although it was the common practice for some time) fault.

I don't think a process per tab is reasonable, I think that would eat too much memory for the extra processes (at first I thought it would also involve too much overhead for the message passing, but as long as tabs don't interact between them, the amount of messaging should remain the same as having all the tabs in a single separate process), but some groups. I don't know, something like four tabs per process or something like this, so you don't lose all of them when one fails badly, but you don't get that much memory overhead.

Just because something is multi-threaded, it doesn't mean it is inherently memory consuming. But, this is firefox we're talking about here, so yeah, it'll probably be a disaster.

Maybe what would be the most ideal is a separate process per group. I know most people don't use groups in firefox, but doing this would be a lot more reasonable in terms of performance vs memory consumption vs dependability.

[KellyClowers]

Just because something is multi-threaded, it doesn't mean it is inherently memory consuming. But, this is firefox we're talking about here, so yeah, it'll probably be a disaster.

Maybe what would be the most ideal is a separate process per group. I know most people don't use groups in firefox, but doing this would be a lot more reasonable in terms of performance vs memory consumption vs dependability.

Or by window might not be too bad. I don't use groups, but my 50-200 tabs are usually spread over 2-4 windows for different tasks.

[mrugiero]

Just because something is multi-threaded, it doesn't mean it is inherently memory consuming. But, this is firefox we're talking about here, so yeah, it'll probably be a disaster.

Yes, it does mean that. Processes take up extra memory compared to threads, and again, we are not talking of multi threading but multi process. One single extra thread (admittedly, without any work put in mitigating those effects) meant 10 extra MB of memory use, according to the blog post. If you use few tabs, that's a non problem, but if you keep a lot of tabs open, this is a 10MB (maybe less, but the point is the same) multiplied by the number of tabs of extra memory use. 40 tabs means 400MB, if you use a process per tab. Threads are more lightweight, but apparently harder to work with, and as they are part of the same process, if one makes something illegal like dereferencing a null pointer, the whole comes down.

Maybe what would be the most ideal is a separate process per group. I know most people don't use groups in firefox, but doing this would be a lot more reasonable in terms of performance vs memory consumption vs dependability.

What do you mean by "groups"? I don't know the feature, at least not by name. Does it have anything to do with panorama?
EDIT: Looked for it and it is exactly that. I use them. I just lost them by recklessly trying the feature in my usual profile, without checking that history is not yet supported. That sounds like a better approach, I agree.

[plonoma]

You could split the threads:
y GUI threads
x rendering, worker threads.
- separate threads for visible and non visible tab.
Each window should get it's own GUI threads until some maximum number of threads, say number of CPU cores, is reached.
Each visible tab should get it's own thread until some maximum number of threads, say number of CPU cores, is reached. This configuration minimizes latency and maximizes cpu resources while not inefficiently using cpu cores the memory by avoiding tons of threads.
.
Then also a number of threads for non visible tabs, say number of CPU cores to maximize performance and computing resources.
As long as the number of non visible tabs are below the number of CPU cores, then each non visible tab gets it's own thread.

This allows good latency, performance, allocation of CPU resources while not making tons of threads that are not needed.

[plonoma]

Meant in previous post:
This configuration minimizes latency and maximizes cpu resources while efficiently using cpu cores and the memory by avoiding tons of threads.

And last line supposed to be:
This allows good latency, performance, allocation of CPU resources while not making tons of threads that take tons of memory.

[plonoma]

From: http://www.mozilla.org/en-US/firefox.../releasenotes/

25.0.1: Pages sometimes wouldn't load without first moving the cursor

Having page load behaviour depend upon moving the mouse cursor.
Note how it does not speak about hovering or clicking or anything like that.
Is a serious flaw that says there is a very incompetent developer amongst their midst.

Someone who is incapable of thinking about abstract concepts very well is writing abstract web browsing software at Mozilla.
That developer should be fired or if a volunteer contribution, be denied to contribute substantial changes to Firefox without thorough inspection.

[balouba]

a few precisions..


- yeah electrolysis was stopped, but it's been worked on again. a lot of the work came from firefox os and fennec

- it's nowhere near good enough on desktop, they won't release this for a while

- flash doesn't crash firefox (it's a separate process since years now), but since most things are in the same synchronized thread, it will freeze it until the watchdog timer kicks in, which is 30 full seconds. you an go in your task manager and kill plugin container if you don't wanna wait. multiprocess fx will ensure only a tab is frozen in this condition. That's one of the main reasons for multiprocess firefox.

- same issue with intensive javascript or extremely complex rendering

- firefox is faster than chrome in my JS and non-JS tests. chrome in faster in some. Generally, they're neck-in-neck. there no such thing as chrome behind faster anymore, since at least a year. its also noticeable in usage

- fennec (android firefox) uses a process for the UI and a process everything else. its perhaps the most used browser on android. as good as chrome is on the desktop, it still sux on android. heck, no addons either.

[abral]

"there hasn't been much work in recent time on the Firefox desktop browser to better utilize multiple threads"

Actually Firefox is multi-threaded and in the last years threads are being used more and more (for example in the JavaScript engine).

Firefox is also already using multiple processes for its thumbnailing feature (last I checked).