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

131–140 of 346 posts

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

#131

Post by antisthenes »

wongarsu wrote: post #76
azinman2 wrote: post #64

Earlier quoted context omitted.

Maybe I'm misreading things but it looks like it's been constantly getting worse since 2012?

They're getting worse at a linear pace, while hardware improves exponentially. Effectively that's a pretty good improvement each year.

Not only is this false, but completely ignores troves of older hardware existing in people's homes that has to run browsers just as well.

The average consumer hardware improves at nowhere near exponential rate (although I guess it depends on the timescale and your willingness to fudge the graph to sparse data points).

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

#132

Post by wldcordeiro »

nbadg wrote: post #125
alyandon wrote: post #70

Earlier quoted context omitted.

I'm currently at a little over 1 GB with 8 tabs open. I really wish I had the option to trade off responsiveness for memory usage by being able to mark tabs as "no background activity allowed" so FF could serialize that content to disk when the tab isn't in focus.

For a reference point on scaling, on a Windows 7 machine that hasn't been shutdown in a week or two, I have a long-running Firefox session with 5 windows and 80-something tabs, and I'm at 1.7 GB. Half a GB of that is being consumed by the Google Music player.

I've noticed Google Play Music is heavy. It can easily consume half a GB or more on my machine. I think at this point the browsers are doing the best job they can but it's pretty telling that it's the web apps/sites we use that cost us memory.

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

#133

Post by bzbarsky »

faragon wrote: post #12

Why? Except because of memory allocation serialization impact, there is no reason for a multithreaded process being slower than multiprocess. And if that's the cause, it could be solved using multiple heaps.

The current setup is not multithreaded in the relevant ways.

So the real decision point was whether to take an existing large C++ codebase and try to safely make it multithreaded or to take that same existing codebase, run it in separate processes, and make the communication work.

The latter is actually a simpler engineering task, in my opinion, and paves the way for doing things like sandboxing and whatnot once the initial rollout is complete.

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

#134

Post by [deleted] »

rsp1984 wrote: post #19

“We can learn from the competition,” said Dotzler. “The way they implemented multi-process is RAM-intensive, it can get out of hand. We are learning from them and building an architecture that doesn’t eat all your RAM.” That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff…

[deleted]

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

#135

Post by sdabdoub »

Lagged2Death wrote: post #101
azinman2 wrote: post #64

Earlier quoted context omitted.

Maybe I'm misreading things but it looks like it's been constantly getting worse since 2012?

The FAQ says: TP5 loads 100 popular webpages, served from a local webserver. I don't know if that means the test pages are up-to-date copies of real-world pages or not. On one hand, real-world pages have certainly been getting heavier, and it would bear mentioning if that fact was not reflected in this test. On the other hand the graph becomes really hard to interpret if the test suite isn't a constant.

The actual pageset appears to live on build.mozilla.org[1], but is down atm (for me at least). The actual list of pages is on the areweslimyet github repo[2].

[1]https://build.mozilla.org/talos/zips/tp5.zip

[2]https://github.com/mozilla/areweslimyet/blob/a42e69eaac4c764...

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

#136

Post by scrollaway »

bzbarsky wrote: post #128
scrollaway wrote: post #52

Earlier quoted context omitted.

Firefox is frustratingly slow for me. I can't use it, have to stick to Chrome. Chrome which, by the way, crashes after 5 minutes of using video Hangouts and brings my 16 gigabytes ram PC to a halt when I open too many youtube tabs. But firefox scrolling is especially slow. irccloud.com is the main culprit (and I use irccloud a lot). It's pretty bad in gmail as well. The react app my team is working on is also far slo…

That last link looks about the same to me in Chrome dev and Firefox nightly, for what it's worth.

Dragging the scrubber around updates at the same speed, really? I'm not on Nightly, maybe that's the difference, but if that's the case that's great news.

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

#137

Post by mstange »

scrollaway wrote: post #52
nl wrote: post #7

I switched to Firefox from Chrome about 12 months ago. It isn't as good as Chrome, but I was trying to reduce my Google dependencies. It has been mostly fine (except for an annoying OS-X multi-screen bug where it screws up the sizing). I was really looking forward to this feature to help close the gap on Chrome performance. Until August (I think Firefox 48.x), when it became unusable on any site with... something. I'…

Firefox is frustratingly slow for me. I can't use it, have to stick to Chrome. Chrome which, by the way, crashes after 5 minutes of using video Hangouts and brings my 16 gigabytes ram PC to a halt when I open too many youtube tabs. But firefox scrolling is especially slow. irccloud.com is the main culprit (and I use irccloud a lot). It's pretty bad in gmail as well. The react app my team is working on is also far slo…

Scrolling especially should be much better in multi-process Firefox, because it will be async, so web pages no longer block it.

It doesn't fix performance in your react app, though. I've filed a bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1300848

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

#139

Post by mstange »

bzbarsky wrote: post #128
scrollaway wrote: post #52

Earlier quoted context omitted.

Firefox is frustratingly slow for me. I can't use it, have to stick to Chrome. Chrome which, by the way, crashes after 5 minutes of using video Hangouts and brings my 16 gigabytes ram PC to a halt when I open too many youtube tabs. But firefox scrolling is especially slow. irccloud.com is the main culprit (and I use irccloud a lot). It's pretty bad in gmail as well. The react app my team is working on is also far slo…

That last link looks about the same to me in Chrome dev and Firefox nightly, for what it's worth.

It's 5-10 fps in Firefox Nightly for me, and 50-60 fps in Chrome Canary, on OS X.

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

#140

Post by luckydude »

alyandon wrote: post #70
marcosdumay wrote: post #60

Earlier quoted context omitted.

Funniest thing is that FF memory usage didn't go down that much. For me it is even higher.

I'm currently at a little over 1 GB with 8 tabs open. I really wish I had the option to trade off responsiveness for memory usage by being able to mark tabs as "no background activity allowed" so FF could serialize that content to disk when the tab isn't in focus.

I'm at 2.9G virtual 1.277g resident with about 130 tabs open (yeah, I'm a goofball but I like my tabs). It's pretty responsive on a thinkpad x220 i5-2540M @ 2.6ghz, 8G of ram and an SSD.
Post reply on HN