4 ms·

"No Multi-Process Architecture" This is a feature, and I like it. The rest is just flamebait.

by Gmo 13y ago

VLM 13y ago
The article was meant for very non-technical users, but I did find it hilarious that the task manager proving the superiority of chrome because each tab has a separate process so delays in one tab don't affect delays in other tabs showed... 0% CPU utilization on them all. So whereas chrome has X number processes each using 0% for a total of 0*0=0% use, firefox would just have 0% cpu on its one process for a total of 0% use, obviously a substantial difference between FF and Chrome LOL. I use both and the main thing I notice is they're so similar that you'll see articles from one or the other trying to differentiate themselves from the other to gain user share, as if the users can tell the difference. Even the addon / extension names are either the same or about the same.
hdra 13y ago
how is this a feature?
- dbaupp 13y ago
  Lower memory usage (I think).
  - zanny 13y ago
    You know, because the reason there are threads in the first place is that a single running process can share its global variables and heap space. When Chrome runs in multiple processes, it has to duplicate its global (mostly static) variable space each time. Albeit, that is certainly peanuts next to the v8 interpreters heap, the web page itself, loaded images, etc, but there is a reason few programs do the multi-process thing. Chrome doesn't really get a speedup from it, it gets a stability bump. If one tab crashes in Chrome a tab goes, if a tab in firefox goes it drops the whole browser process. As a development design pattern, if you are concerned with stability, you fork your threads into their own processes and prepare for them to go down in flames.
- Gmo 13y ago
  I have more than a 100 tabs open at once, it DOES add up.
  - artmageddon 13y ago
    So you're for or against Firefox using a multi-processor architecture? For me, FF becomes unbearably slow when I have about 15-20 tabs open.
    - dbaupp 13y ago
      For me, everything except FF is unbearably slow and memory-hog-y with more that that many tabs.
    - belorn 13y ago
      I'm not sure whats causing your 15-20 tabs to slow down the browser, but I managed at one time to build up over 256 tabs[1], and I can't say I noticed any performance drop over having single digit tabs. I haven't tested doing that in chrome, through I suspect the individual processes with no shared memory (sandboxing) would cause some trouble. [1]: Restore tabs on exit. If one do not clean up after a while, the tabs will just continue to increase.
    - pessimizer 13y ago
      That's got to be an addon problem. I can't remember the last time I had less than 15-20 tabs open. I have to get to 80-100 before I start feeling any misery.
      - artmageddon 13y ago
        I'll have to look into that. I run Ghostery, Adblock and Reddit enhancement suite, but that's it.
narag 13y ago
Not a very informative comment, but I mostly agree. I use both browsers and never noticed any real annoyance in the Mozilla side. I don't know if the author is trying to make Mozilla prioritize his desired features, but the years-behind metric doesn't sound very friendly, or used-centered for the matter.
vy8vWJlco 13y ago
And there is a simple solution to that (poor multi-core utilization): go back to a one-window, one process model (go back, as in delete a lot of unnecessary code); forget the browser tabs - let the OS handle multitasking and let the window manager handle the windows.
- randallu 13y ago
  The hard stuff isn't the window system/widget integration, it's having multiple processes open for the same domain (or iframes in different processes) and mediating access to local storage/IDB/cookie jar/network cache/etc. It was only very recently that WebKit2 handled most of this stuff -- up until then they just had a single WebProcess (I think Safari on Mavericks is the first multi-WebProcess browser Apple have shipped). So it's a hard problem and isn't due to some lack of competence that Mozilla have been slow to adapt. FxOS is fully multiprocess afaik. Actually getting the rendered page image into a window owned by another process is easy: windows and X let you host HWNDs and Windows from other processes (if you choose to allow your WebProcesses access to the window server) or you could draw into a shared memory segment. The hard stuff is all of the regular browser hard stuff.
  - vy8vWJlco 13y ago
    I can't accept your complicated worldview. Iframes, for example, don't need to be new processes. One process - one window - one DOM. The only new process should be the rendering canvas/window. An iframe, or any nested resources can re-use cookies associated with a window/process, including caching. In order to persist tokens/cookies/cache between processes you hand them their own copy when you spin them up and write them out to a common, re-usable place when you close, but for the most part I consider browser statefulness to be more like a flaw than a feature (I constantly clear my cookies, form data, and history). how about a "save session" button, rather than the default being to cache objects and cookies in some common blocking profile that only allows one session and that, when it crashes, it all comes down... If you really want to share, you wrap those services up in a library - which is closer to the present model - but you have to know that in doing so you are making it harder to isolate things when they fail... And isn't that what's wrong with most browsers?
randallu 13y ago
The current round of multi-process architectures (that is: Chrome) don't really scale though. After you have so many renderer processes they start shoving unrelated pages together, so if you short-lived heap-fragmenting pages bundled into the process of a long-lived page then you lose your memory "forever", even when you close the short-lived bad tag. I wonder if you could keep every page in its own process, but manually freeze unused processes and write them out to disk -- an application driven disk paging system basically. For pages where there's no state the browser could just kill them and reload them, iOS style (though the iOS browser doesn't care if it nukes state).

"No Multi-Process Architecture" This is a feature, and I like it. The rest is just flamebait.

by Gmo 13y ago

"No Multi-Process Architecture" This is a feature, and I like it. The rest is just flamebait.

VLM 13y ago

The article was meant for very non-technical users, but I did find it hilarious that the task manager proving the superiority of chrome because each tab has a separate process so delays in one tab don't affect delays in other tabs showed... 0% CPU utilization on them all. So whereas chrome has X number processes each using 0% for a total of 0*0=0% use, firefox would just have 0% cpu on its one process for a total of 0% use, obviously a substantial difference between FF and Chrome LOL. I use both and the main thing I notice is they're so similar that you'll see articles from one or the other trying to differentiate themselves from the other to gain user share, as if the users can tell the difference. Even the addon / extension names are either the same or about the same.

hdra 13y ago

how is this a feature?

dbaupp 13y ago
Lower memory usage (I think).
- zanny 13y ago
  You know, because the reason there are threads in the first place is that a single running process can share its global variables and heap space. When Chrome runs in multiple processes, it has to duplicate its global (mostly static) variable space each time. Albeit, that is certainly peanuts next to the v8 interpreters heap, the web page itself, loaded images, etc, but there is a reason few programs do the multi-process thing. Chrome doesn't really get a speedup from it, it gets a stability bump. If one tab crashes in Chrome a tab goes, if a tab in firefox goes it drops the whole browser process. As a development design pattern, if you are concerned with stability, you fork your threads into their own processes and prepare for them to go down in flames.
Gmo 13y ago
I have more than a 100 tabs open at once, it DOES add up.
- artmageddon 13y ago
  So you're for or against Firefox using a multi-processor architecture? For me, FF becomes unbearably slow when I have about 15-20 tabs open.
  - dbaupp 13y ago
    For me, everything except FF is unbearably slow and memory-hog-y with more that that many tabs.
  - belorn 13y ago
    I'm not sure whats causing your 15-20 tabs to slow down the browser, but I managed at one time to build up over 256 tabs[1], and I can't say I noticed any performance drop over having single digit tabs. I haven't tested doing that in chrome, through I suspect the individual processes with no shared memory (sandboxing) would cause some trouble. [1]: Restore tabs on exit. If one do not clean up after a while, the tabs will just continue to increase.
  - pessimizer 13y ago
    That's got to be an addon problem. I can't remember the last time I had less than 15-20 tabs open. I have to get to 80-100 before I start feeling any misery.
    - artmageddon 13y ago
      I'll have to look into that. I run Ghostery, Adblock and Reddit enhancement suite, but that's it.

narag 13y ago

Not a very informative comment, but I mostly agree. I use both browsers and never noticed any real annoyance in the Mozilla side. I don't know if the author is trying to make Mozilla prioritize his desired features, but the years-behind metric doesn't sound very friendly, or used-centered for the matter.

vy8vWJlco 13y ago

And there is a simple solution to that (poor multi-core utilization): go back to a one-window, one process model (go back, as in delete a lot of unnecessary code); forget the browser tabs - let the OS handle multitasking and let the window manager handle the windows.

randallu 13y ago
The hard stuff isn't the window system/widget integration, it's having multiple processes open for the same domain (or iframes in different processes) and mediating access to local storage/IDB/cookie jar/network cache/etc. It was only very recently that WebKit2 handled most of this stuff -- up until then they just had a single WebProcess (I think Safari on Mavericks is the first multi-WebProcess browser Apple have shipped). So it's a hard problem and isn't due to some lack of competence that Mozilla have been slow to adapt. FxOS is fully multiprocess afaik. Actually getting the rendered page image into a window owned by another process is easy: windows and X let you host HWNDs and Windows from other processes (if you choose to allow your WebProcesses access to the window server) or you could draw into a shared memory segment. The hard stuff is all of the regular browser hard stuff.
- vy8vWJlco 13y ago
  I can't accept your complicated worldview. Iframes, for example, don't need to be new processes. One process - one window - one DOM. The only new process should be the rendering canvas/window. An iframe, or any nested resources can re-use cookies associated with a window/process, including caching. In order to persist tokens/cookies/cache between processes you hand them their own copy when you spin them up and write them out to a common, re-usable place when you close, but for the most part I consider browser statefulness to be more like a flaw than a feature (I constantly clear my cookies, form data, and history). how about a "save session" button, rather than the default being to cache objects and cookies in some common blocking profile that only allows one session and that, when it crashes, it all comes down... If you really want to share, you wrap those services up in a library - which is closer to the present model - but you have to know that in doing so you are making it harder to isolate things when they fail... And isn't that what's wrong with most browsers?

randallu 13y ago

The current round of multi-process architectures (that is: Chrome) don't really scale though. After you have so many renderer processes they start shoving unrelated pages together, so if you short-lived heap-fragmenting pages bundled into the process of a long-lived page then you lose your memory "forever", even when you close the short-lived bad tag. I wonder if you could keep every page in its own process, but manually freeze unused processes and write them out to disk -- an application driven disk paging system basically. For pages where there's no state the browser could just kill them and reload them, iOS style (though the iOS browser doesn't care if it nukes state).