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

Multi-process Firefox brings 400-700% improvement in responsiveness

techcrunch.com

Post reply on HN
Print view View original

301–310 of 346 posts

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#301

Post by lloeki »

0xfeba wrote: post #32
schoen wrote: post #28

Earlier quoted context omitted.

Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?

Duplicated memory and just overhead from running separate processes (Chrome), as opposed to shared memory and less overhead from a single process (IE? Old FF). As for security, no, unless there's some unknown vulnerability now (or that they create), that will be ported over and somehow more effective between (potential) processes. So, I doubt it.

> Duplicated memory and just overhead from running separate processes

fork(2) does COW. With careful design† forking a new process only results in new and modified pages being not shared.

† Hard! But single-process threads + security is hard too.

http://unix.stackexchange.com/questions/58145/how-does-copy-...

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#302

Post by flukus »

kalleboo wrote: post #297
drzaiusapelord wrote: post #10

Its incredible multi-process took this long. Just goes to show you that your architecture decisions last a long time and are often difficult to change. Chrome had this from day one and never had a big and old codebase to worry about. Yet it took Firefox many years to get multi-process going and my understanding is that its much more limited and simpler than what Chrome or Edge do. I'm also a little surprised there ha…

> I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up. It's interesting how the history goes. We had Netscape 4, and it was crap (remember when resizing a window reloaded the whole page?) So they was a ground-up rewrite of the rendering engine, resulting in Gecko, which was put in Mozilla. Gecko was great but Mozilla was a bloaty amalgamation of features, so…

A few additions:

KHTML was originally forked from QHtml (part of Qt) I believe (or they shared the same origin?).

Webkit later became a Qt component, the circle of life.

I would argue chromes biggest innovation was the UI, putting the address bar as part of the tab where it belongs (cue holy war) and better tabbing in general.

Mozilla was also the first to integrate the search and address fields, which they unfortunately stripped out of firefox (and many people think chrome introduced it).

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#303

Post by AstralStorm »

RussianCow wrote: post #148
AstralStorm wrote: post #88

Earlier quoted context omitted.

Except mobile hardware which does not. Power usage is always a concern.

Power usage has little to do with memory usage. In fact, if the browser is using more RAM as a cache, it won't hit persistent storage as much, which actually increases battery life.

The extra chips are not free. What we are seeing is bringing up the latest low power tech into the phones for now. Except RAM has hit maximum densities per chip already or is very close.

Remember that RAM has to be powered on for every refresh cycle...

It is "nothing" compared to screen or radios, but it is there. So you won't be seeing more than one Dram chip in there, footprint notwithstanding.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#304

Post by AstralStorm »

lloeki wrote: post #301
0xfeba wrote: post #32

Earlier quoted context omitted.

Duplicated memory and just overhead from running separate processes (Chrome), as opposed to shared memory and less overhead from a single process (IE? Old FF). As for security, no, unless there's some unknown vulnerability now (or that they create), that will be ported over and somehow more effective between (potential) processes. So, I doubt it.

> Duplicated memory and just overhead from running separate processes fork(2) does COW. With careful design† forking a new process only results in new and modified pages being not shared. † Hard! But single-process threads + security is hard too. http://unix.stackexchange.com/questions/58145/how-does-copy-...

Only on Linux, POSIX does not mandate CoW and Windows does not have a similar API.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#305

Post by smcl »

srean wrote: post #267
hackuser wrote: post #209

Earlier quoted context omitted.

> I stopped using Firefox because my habit of opening dozens of tabs led to stratospheric memory usages that killed even 16G machines I don't think that's representative of how Firefox works. I used Firefox similarly in 2013 and didn't see those problems; the users supported by my company, mostly on 4GB machines, also didn't see them. I have a 112 tabs open right now and Firefox has been running for a couple of weeks…

I see your 112 and raise you a 875. FF worked just fine that too with just a less than 1 GB of RAM. I had to block flash, hand tune some of the cache sizes and have a tab uloader etc. No other browser seemed capable of handling my rather unique use case.

If you don't mind me asking, what are you doing that you have 875 tabs open? How are you able to keep track of what you opened, and where etc? I tend to feel anxious and unfocussed when I've got over a dozen or so open - at which point i'll dump some "I'd like to read this" articles into a bookmarks folder which I work through in my down-time, and clean out periodically.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#306

Post by creshal »

derefr wrote: post #255
creshal wrote: post #44

Earlier quoted context omitted.

Chrome uses separate processes for sandboxing purposes, not just for the fun of it. So yes, protecting against "some unknown vulnerability" is the entire point behind it.

As a fun fact, separate virtual machines running under a VMWare ESXi hypervisor—which is about as "sandboxed" as you can get—still share memory: the hypervisor hashes the 'cold' pages of its VMs and, when it finds duplicate page content either within or between VMs, it merges the duplicated pages together into single copy-on-write pages. ESXi has never had a security vulnerability due to this optimization, AFAIK. Ref…

> ESXi has never had a security vulnerability due to this optimization, AFAIK.

Should be vulnerable to FFS, if I'm not mistaken: http://arstechnica.com/security/2016/08/new-attack-steals-pr...

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#307

Post by akerro »

cheeze wrote: post #232
akerro wrote: post #156

Earlier quoted context omitted.

ArchLinux 64 https://i.imgur.com/sDqs24a.png

I don't know if anything has changed, but tree style tab gave me terrible memory leaks.

According to about:performance TST has lower memory and CPU usage than uBlock

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#308

Post by [deleted] »

creshal wrote: post #306
derefr wrote: post #255

Earlier quoted context omitted.

As a fun fact, separate virtual machines running under a VMWare ESXi hypervisor—which is about as "sandboxed" as you can get—still share memory: the hypervisor hashes the 'cold' pages of its VMs and, when it finds duplicate page content either within or between VMs, it merges the duplicated pages together into single copy-on-write pages. ESXi has never had a security vulnerability due to this optimization, AFAIK. Ref…

> ESXi has never had a security vulnerability due to this optimization, AFAIK. Should be vulnerable to FFS, if I'm not mistaken: http://arstechnica.com/security/2016/08/new-attack-steals-pr...

[deleted]

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#309

Post by derefr »

creshal wrote: post #306
derefr wrote: post #255

Earlier quoted context omitted.

As a fun fact, separate virtual machines running under a VMWare ESXi hypervisor—which is about as "sandboxed" as you can get—still share memory: the hypervisor hashes the 'cold' pages of its VMs and, when it finds duplicate page content either within or between VMs, it merges the duplicated pages together into single copy-on-write pages. ESXi has never had a security vulnerability due to this optimization, AFAIK. Ref…

> ESXi has never had a security vulnerability due to this optimization, AFAIK. Should be vulnerable to FFS, if I'm not mistaken: http://arstechnica.com/security/2016/08/new-attack-steals-pr...

True! Rowhammer-based attacks are kind of unique, though; I expect they'll be treated as a hardware bug and solved by releasing better hardware, rather than through inventing even more layers of securinoia to keep in mind from now on.

It's sort of like when WebGL was first getting going, and the GPUs of the time didn't expect to be fed shaders directly from potentially-malicious web sources. Rather than severely restricting the WebGL API, we got a new generation of GPUs that fail safe.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#310

Post by jayflux »

Manishearth wrote: post #262
jayflux wrote: post #22

Earlier quoted context omitted.

|| I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up. I (hopefully) think this is what Servo is and will end up being. Has no legacy code, and is tiny in comparison to Gecko. It's OS support is fairly modern, and has no interest in supporting Windows XP. It's also written in such a way that allows them to be more multi-threaded and more concurrent than trad…

> I (hopefully) think this is what Servo is and will end up being. Not really the plan. Servo may eventually become a product, but that would be in the very far future. But Gecko can use lessons learned from Servo, and try to share code with it, so you can incrementally replace parts of Gecko. > and has no interest in supporting Windows XP. I don't think that's the case? We don't have users on XP so we may not suppor…

> Not really the plan.

Yup, hence my "hopefully", I'm aware small parts of servo may go into Gecko incrementally, however im still routing for something like browserhtml to be at a usable state, and for servo to run on its own.

> I don't think that's the case? PR link https://github.com/servo/servo/issues/1908 https://www.reddit.com/r/rust/comments/2vg0g1/this_week_in_s...

It might be worth making it clear what Servo's OS support is going to be, (for now and in future) to save any confusion

Post reply on HN