3 ms·

No processes. No hangouts. No index service started without asking. Chrome on Windows is a pig. Back when I was using it then nonstop then 25% of CPU usage was

by mybrid 10y ago

No processes. No hangouts. No index service started without asking. Chrome on Windows is a pig. Back when I was using it then nonstop then 25% of CPU usage was pegged to Chrome. I gave up trying to manage Chrome and switched to Firefox. Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess. Also, I like the implementation of profiles in Firefox much better. I have a different profile for work, home and various side jobs. Very nice. Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction.

nextos 10y ago
I love Firefox because it's like the Emacs of browsers [1]. It's self-discoverable, it can be scripted and it has dozens of wonderful extensions. To me, dropping their plugin architecture to achieve compatibility with Chrome is a bit absurd. Vimperator, GreaseMonkey and many others make Firefox unique. [1] I know there's Conkeror, but the project seems to have stalled.
- yellowapple 10y ago
  Not only has Conkeror stalled, but scrapping XUL is a surefire way to murder it in cold blood. The only option going forward would be to rewrite it as an alternate browser that uses Gecko and/or Servo as the engine. My hope is that the move to WebExtensions will actually help here. Currently, Conkeror is theoretically compatible with Firefox extension-wise, but it often meant writing a bunch of glue code to expose Firefox extension functionality without Firefox' actual UI. Now that extensions are forced to be UI agnostic, it seems reasonable that a browser that's Firefox-compatible could have a much easier time with that. Hopefully a post-XUL Firefox will continue to support something along the basic lines of XULRunner (i.e. present a Firefox window without the actual UI) to make that easier than having to fork Firefox itself.
sf_rob 10y ago
>No processes From my understanding, the initial rollout of multi-process has a single render process (in addition to the main browser process). There are ongoing experiments to determine the optimal number of processes, so it's likely to increase soon. In the future you can force this to 1 by using the "dom.ipc.processCount" pref if you don't want your process manager to resemble Chrome.
- cpeterso 10y ago
  That's correct. Firefox currently uses one main browser process, one content process (for all tabs), and a plugin sandbox process. Multiple content processes (aka "e10s-multi") are coming soon, currently two content processes are the default in Firefox Developer Edition (53) and Nightly (54). More content processes will be added, though the Firefox team is quite aware of the concerns about memory usage. The next step will probably be four content processes plus a ServiceWorker process. https://wiki.mozilla.org/Electrolysis/Multiple_content_processes https://wiki.mozilla.org/Electrolysis/Multiple_content_proce...
- yellowapple 10y ago
  I feel like that defeats the point of multiprocess; on Chrome at least, the one-process-per-tab model is intended to isolate tabs from one another without having to duplicate a bunch of work that the OS does already.
  - sf_rob 10y ago
    You're correct that it defeats one of the points of multiprocess, but you still get parallel performance gains trivially that will scale well as more cores are added as well as isolation of crashes where it doesn't kill your whole session.
ploxiln 10y ago
> Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. This might undermine the rest of your argument. Chrome developers are pretty damn sharp, and they use processes so they can add features the fastest while maintaining the best security profile (and record). But I agree with your overall point. I'm saddened by the need for the browser to suck up more and more of my computer's resources - more gigabytes of ram, more cores - in order to enable web developers to develop ever-flashier applications faster. The balance has swung way too far, web applications (and even static content sites) need to be less flashy, and spend more time on reasonably sane implementations and libraries. I'm also sad that Firefox is pressured into just doing what Chrome does. But I can understand, they don't see an alternative, they have to "keep up" with websites and user bases that can't be trusted.
zerocrates 10y ago
What does Firefox do with profiles that isn't supported by Chrome's "persons" or whatever they're called? The extensions, histories, settings, etc. are separate in different Chrome profiles, I'm not sure what more I'd want them to do.
nephyrin 10y ago
> Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess. Your argument against a multi-process architecture is you once encountered a process-reaping bug in chrome. Can't even. > I refuse to use Chrome because it has crappy performance and usability. I worked as a platform engineer at Mozilla for several years. I heard so many unfounded opinions about <browser>'s <performance/memory/whatever> consumption that ran contrary to every benchmark and defied every attempt to extract statistics from the user that you'd think I would be numb to it. But I still get chills. The advice was always the same though. "Does this occur if you open a fresh profile without your 900 tabs or 50 addons?" -- "If I'm going to do that I might as well switch to Chrome!" -- Well, I mean, okay. > Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction. This is insulting to a lot of very smart people who spent an enormous amount of time working on these engines. You can't just infer two traits about random software, attribute it to the biggest technical difference you can see, and then state that as fact. A multi-process architecture is much more difficult to get right than a multi-threaded one, and every single modern browser is pursuing it because it is worthwhile on numerous axis. Citing nothing but a vague luddite sentiment, you assert the hundreds of engineers who have spent years working on chrome don't "have the chops" to "do threads". Wat.
RaleyField 10y ago
> Recently Firefox said they were moving away from threads to processes. I think that's a mistake. It's the only reason I'm still on Chrome/Chromium. I like my exploding processes to be in a sandbox, but that's just me. It's been 10 years since Vista RTM'd and Firefox lagging behind IE. Still a bigger wonder is that the same company is also behind Rust - if you care about security why not put your browser in a sandbox first?
chikei 10y ago
Fortunately (at least for now), Firefox uses N:M process:thread model instead of 1:1 like chrome (I am typing this in Firefox with 40+ tabs but using only two processes and with a chrome with single OneTab's tab using 10+ processes....) and it allows you to turn off e10s in about:config.

by mybrid 10y ago

nextos 10y ago

I love Firefox because it's like the Emacs of browsers [1]. It's self-discoverable, it can be scripted and it has dozens of wonderful extensions. To me, dropping their plugin architecture to achieve compatibility with Chrome is a bit absurd. Vimperator, GreaseMonkey and many others make Firefox unique. [1] I know there's Conkeror, but the project seems to have stalled.

yellowapple 10y ago
Not only has Conkeror stalled, but scrapping XUL is a surefire way to murder it in cold blood. The only option going forward would be to rewrite it as an alternate browser that uses Gecko and/or Servo as the engine. My hope is that the move to WebExtensions will actually help here. Currently, Conkeror is theoretically compatible with Firefox extension-wise, but it often meant writing a bunch of glue code to expose Firefox extension functionality without Firefox' actual UI. Now that extensions are forced to be UI agnostic, it seems reasonable that a browser that's Firefox-compatible could have a much easier time with that. Hopefully a post-XUL Firefox will continue to support something along the basic lines of XULRunner (i.e. present a Firefox window without the actual UI) to make that easier than having to fork Firefox itself.

sf_rob 10y ago

>No processes From my understanding, the initial rollout of multi-process has a single render process (in addition to the main browser process). There are ongoing experiments to determine the optimal number of processes, so it's likely to increase soon. In the future you can force this to 1 by using the "dom.ipc.processCount" pref if you don't want your process manager to resemble Chrome.

cpeterso 10y ago
That's correct. Firefox currently uses one main browser process, one content process (for all tabs), and a plugin sandbox process. Multiple content processes (aka "e10s-multi") are coming soon, currently two content processes are the default in Firefox Developer Edition (53) and Nightly (54). More content processes will be added, though the Firefox team is quite aware of the concerns about memory usage. The next step will probably be four content processes plus a ServiceWorker process. https://wiki.mozilla.org/Electrolysis/Multiple_content_processes https://wiki.mozilla.org/Electrolysis/Multiple_content_proce...
yellowapple 10y ago
I feel like that defeats the point of multiprocess; on Chrome at least, the one-process-per-tab model is intended to isolate tabs from one another without having to duplicate a bunch of work that the OS does already.
- sf_rob 10y ago
  You're correct that it defeats one of the points of multiprocess, but you still get parallel performance gains trivially that will scale well as more cores are added as well as isolation of crashes where it doesn't kill your whole session.

ploxiln 10y ago

> Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. This might undermine the rest of your argument. Chrome developers are pretty damn sharp, and they use processes so they can add features the fastest while maintaining the best security profile (and record). But I agree with your overall point. I'm saddened by the need for the browser to suck up more and more of my computer's resources - more gigabytes of ram, more cores - in order to enable web developers to develop ever-flashier applications faster. The balance has swung way too far, web applications (and even static content sites) need to be less flashy, and spend more time on reasonably sane implementations and libraries. I'm also sad that Firefox is pressured into just doing what Chrome does. But I can understand, they don't see an alternative, they have to "keep up" with websites and user bases that can't be trusted.

zerocrates 10y ago

What does Firefox do with profiles that isn't supported by Chrome's "persons" or whatever they're called? The extensions, histories, settings, etc. are separate in different Chrome profiles, I'm not sure what more I'd want them to do.

nephyrin 10y ago

> Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess. Your argument against a multi-process architecture is you once encountered a process-reaping bug in chrome. Can't even. > I refuse to use Chrome because it has crappy performance and usability. I worked as a platform engineer at Mozilla for several years. I heard so many unfounded opinions about <browser>'s <performance/memory/whatever> consumption that ran contrary to every benchmark and defied every attempt to extract statistics from the user that you'd think I would be numb to it. But I still get chills. The advice was always the same though. "Does this occur if you open a fresh profile without your 900 tabs or 50 addons?" -- "If I'm going to do that I might as well switch to Chrome!" -- Well, I mean, okay. > Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction. This is insulting to a lot of very smart people who spent an enormous amount of time working on these engines. You can't just infer two traits about random software, attribute it to the biggest technical difference you can see, and then state that as fact. A multi-process architecture is much more difficult to get right than a multi-threaded one, and every single modern browser is pursuing it because it is worthwhile on numerous axis. Citing nothing but a vague luddite sentiment, you assert the hundreds of engineers who have spent years working on chrome don't "have the chops" to "do threads". Wat.

RaleyField 10y ago

> Recently Firefox said they were moving away from threads to processes. I think that's a mistake. It's the only reason I'm still on Chrome/Chromium. I like my exploding processes to be in a sandbox, but that's just me. It's been 10 years since Vista RTM'd and Firefox lagging behind IE. Still a bigger wonder is that the same company is also behind Rust - if you care about security why not put your browser in a sandbox first?

chikei 10y ago

Fortunately (at least for now), Firefox uses N:M process:thread model instead of 1:1 like chrome (I am typing this in Firefox with 40+ tabs but using only two processes and with a chrome with single OneTab's tab using 10+ processes....) and it allows you to turn off e10s in about:config.