Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiprocess Firefox

developer.mozilla.org

Post reply on HN
Print view View original

61–70 of 171 posts

Re: Multiprocess Firefox

#61

Post by [deleted] »

_wmd wrote: post #42
suprgeek wrote: post #27

Please please test battery life impact while implementing the Multi-process stuff. I had to move away from Chrome just on the battery life issue. I suspect (but cannot conclusively prove) that the multi-process crap that Chrome has just drains your battery much faster. And yes I am perfectly aware of the supposed fix in Chrome for the battery killing bug.

There's no inherent reason why multiprocess would have a significant impact on energy, it just adds a relatively small amount of extra context switching and marshalling to what is already a huge pile of the same (your desktop OS). When the system is idle, or a page is rendered, the difference shouldn't be measurable.

[deleted]

Re: Multiprocess Firefox

#62

Post by wanderr »

Excavator wrote: post #23
nly wrote: post #14

Earlier quoted context omitted.

Chromium circa 2008?

A browser being built from the ground up around one process per tab has an easier time implementing said feature than one with years of history? Who would've thought‽

The fact that they spent years arguing against its necessity rather than working on it certainly didn't help.

Re: Multiprocess Firefox

#63

Post by StavrosK »

yborg wrote: post #53
_wmd wrote: post #45

Earlier quoted context omitted.

Multiprocess isn't some magical panacea, its use is essentially to contain buggy code which shouldn't exist in the first place (this is true for its use as introducing extra security context for page content as well as its improvements to robustness against hangs). In both instances, a safer implementation language, or moving rendering and JS interpretation off the UI thread could be said to be far more elegant solut…

This. I am a SW tester and regularly use all the major browsers. I frankly do not see any lack in the current non-multiprocess FF in terms of the majority of browsing scenarios. If you really want the browser to be the operating system multi-processing is important, but for those not as interested in Google's agenda it isn't nearly as pertinent.

Really? I switched to FF from Chrome and it's my #1 gripe. I can't load a YouTube video without the entire browser freezing, it's ridiculous.

Re: Multiprocess Firefox

#64

Post by viraptor »

mraison wrote: post #59
viraptor wrote: post #46

Earlier quoted context omitted.

It may have less performance for various reasons, but it can't be less concurrent by definition. Previously there was no concurrency.

You can have concurrency with only one thread. What you cannot have is parallelism. More context here: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

Yes, and I believe that before the layout didn't happen concurrently with other stuff in the browser. It was called on a change and the rest of processing waited. Is that not right?

Re: Multiprocess Firefox

#65

Post by witty_username »

mitchi wrote: post #43
zapt02 wrote: post #2

Finally some movement on this! It really feels like an inferior experience in 2015 when your browser freezes from an unresponsive javascript in another tab.

Chrome crashes and freezes all the time too.

Not for me, I have barely had any crashes or freezes with Chrom(ium).

Re: Multiprocess Firefox

#67

Post by fencepost »

forrestthewoods wrote: post #41
nly wrote: post #14

Earlier quoted context omitted.

Chromium circa 2008?

Yes. Exactly like that. Firefox is damn near a full decade behind the curve.

It's not that it's a full decade behind the curve, it's a decade behind where your perceived curve. There are advantages and disadvantages to both monolithic kernel and microkernel operating systems^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H browsers.

Re: Multiprocess Firefox

#68

Post by TheLoneWolfling »

pekk wrote: post #51
solve wrote: post #7

Goodbye RAM :) Or better for RAM, since I can now selectively kill and resume processes? Oh, I see it's not one process per tab. So does anyone know how I can more easily survive on 2GB with many tabs, other than by constantly killing processes?

Multiple processes does not necessarily mean increased memory usage. I'm a little surprised at how many misinformed comments there are like this.

The problem is this: Chrome. Which, last time I checked, often ends up with >100MB private working set per tab.

And given the amount of dev time that's gone into Chrome / Chromium, it doesn't exactly set a good precedent.

Also, you're missing that there are a number of things that have to be duplicated in a multiprocess model that you only need one of in a multithreaded model. For instance: the JS heap, which has a reasonable amount of overhead.

Some things can be shared between processes like they can be between threads, but not everything.

Re: Multiprocess Firefox

#69

Post by cpeterso »

StavrosK wrote: post #63
yborg wrote: post #53

Earlier quoted context omitted.

This. I am a SW tester and regularly use all the major browsers. I frankly do not see any lack in the current non-multiprocess FF in terms of the majority of browsing scenarios. If you really want the browser to be the operating system multi-processing is important, but for those not as interested in Google's agenda it isn't nearly as pertinent.

Really? I switched to FF from Chrome and it's my #1 gripe. I can't load a YouTube video without the entire browser freezing, it's ridiculous.

Are the freezing YouTube videos using Flash or HTML5 video? What OS are you on?

Re: Multiprocess Firefox

#70

Post by jordanthoms »

Infinitesimus wrote: post #58
suprgeek wrote: post #27

Please please test battery life impact while implementing the Multi-process stuff. I had to move away from Chrome just on the battery life issue. I suspect (but cannot conclusively prove) that the multi-process crap that Chrome has just drains your battery much faster. And yes I am perfectly aware of the supposed fix in Chrome for the battery killing bug.

If you were on windows and on chrome before 39 (I think), the battery bug was often because chrome forcibly set the system clock tick rate higher than (arguably) necessary. Should be fixed now though at least according to the bug tracker

They made some battery improvements on Windows, but it's still a huge battery hog on Mac.
Post reply on HN