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

271–280 of 346 posts

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

#271

Post by brokenmachine »

arcatek wrote: post #71
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?

There's more and more features every month. Add that to the various performance improvements (that can take a hit on the ram, dependending on how they're implemented), and it becomes a bit more understandable why you would see such an increase.

Interesting choice of words, you would think "performance" improvements would make things better, not worse...

I do get what you're saying though.

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

#272

Post by cpeterso »

wldcordeiro wrote: post #132
nbadg wrote: post #125

Earlier quoted context omitted.

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.

Google Play Music uses Flash in Firefox (but not in Chrome), so part of the memory usage is out of Mozilla's control.

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

#273

Post by brokenmachine »

nextos wrote: post #230
zobzu wrote: post #226

Earlier quoted context omitted.

honestly its been years now that FF is one of - if not the - browser which uses the least amount of RAM. Its also one of the most energy efficient on most platforms.. (edge is more efficient on Windows, though it does not take into account that the engine is always running even if another browser is in use)

I can second the energy efficient thing, at least in Linux. I've been tracking lots of programs with powertop, including many browsers, in the quest of an efficient desktop and Firefox is pretty good. I also appreciate its great plugins. With vimperator I can configure Firefox using a dotfile, and setup lots of neat things like: 1. A ssh proxy mode that also routes DNS queries set! network.proxy.socks=localhost set!…

Could you please give a little more info about ssh through vimperator? Can it do local port forwarding?

I couldn't find much doing a google search for "vimperator ssh".

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

#274

Post by cesnja »

fbender wrote: post #238
cesnja wrote: post #165

Earlier quoted context omitted.

I occasionally experience similar slowness. In my case, it's caused by bloated sqlite database. After I delete all history, the browser is snappy again.

Mind filing a bug with specifics at bugzilla.mozilla.org? There's probably some low-hanging fruit there …

I would, but just recently purged all my history, so I don't have a reference about database size and number of entries. That means I can't include any constructive data in the bug report.

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

#275

Post by tdkl »

charlee wrote: post #182
tdkl wrote: post #180

Earlier quoted context omitted.

Based on CAF Chromium, with integrated ad-blocker and DuckDuckGo as an search option : https://play.google.com/store/apps/details?id=com.mokee.yubr...

interesting...does this really sync with your Google account / bookmarks?

Yeah, works fine. It did clear the password storage at initial sync, don't know if this was because of Chrome to Chromium switch, but I wasn't bothered since I use a password manager anyway and was planning to clear the passwords. Sync works as the normal Chrome one.

You can get Chromium for desktop with sync and codecs as well : https://github.com/henrypp/chrlauncher

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

#276

Post by frik »

mnarayan01 wrote: post #161
mintplant wrote: post #83

Earlier quoted context omitted.

Have you given the built-in Firefox dev tools a try? If so, what did you feel was missing?

Really just that I've used Firebug for so long that using anything else is painful . I've tried switching but always ended up going back. Much of it is interface differences, but some of it is actual differences in functionality: if Firebug has something which another inspector does not, then it's super-frustrating. If another inspector has something that Firebug lacks, then I don't even notice. Edit: I should emphas…

I would really miss the DOM tab of Firebug. You can explorer the DOM state which is very useful. Non of the other DevTools anywhere has that feature to my knowlegde.

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

#277

Post by brokenmachine »

nirvdrum wrote: post #250
juandazapata wrote: post #247

Earlier quoted context omitted.

Or you can buy 2GB of RAM with those $30

We've reached a point where a lot of consumer hardware simply can't be upgraded. The ideal of just adding more RAM isn't possible (or perhaps practical in many cases). MBPs can't be upgraded at all these days. My Lenovo laptop can, but going 16 GB -> 32 GB requires far more than $30 since I'd need to buy 16 GB SODIMMs. That's also a bit beside the point. I have a workstation with 48 GB RAM. I left a browser running i…

The scenario you describe with one tab using 20Gb is "beside the point" and certainly an exceptional situation. I've never seen that happen... I think I've had one Firefox crash this year, and that time it wasn't using all the RAM - it was hogging 100% CPU instead.

Of course the extra 2Gb might help for someone with less than 48Gb in their machine (most of us!).

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

#278

Post by brokenmachine »

derefr wrote: post #254
dTal wrote: post #162

Earlier quoted context omitted.

All the mobile browsers I've tried do this - Firefox, Dolphin, and stock Android. I distinctly remember browsing the web quite happily with Firefox desktop on a machine with 512 MB of RAM as recently as 2008, so I can't help but feel we've gone backwards.

Am I the only one who loves this behavior? I'd be perfectly happy forcing Chrome/Firefox/etc. into a 1GB sandbox and then telling it to "unload tabs on memory pressure." I only use a few tabs at a time; a simple LRU OOM-eviction algorithm should work wonders.

Maybe you're the only one. I hate waiting for a tab to reload from the network unnecessarily, especially on mobile!

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

#279

Post by derefr »

srean wrote: post #268
derefr wrote: post #253

Earlier quoted context omitted.

How about detecting the pages that don't have stateful elements, and then only serializing those?

With applications written in javascript ? Stateful on the client side alone or stateful on both sides ? It wont be safe to assume that state is persisted transparently on the server side. May be they just cache it for a while. To make this work reliably would be quite difficult.

You could be really conservative: only assume statelessness if the page has no elements and has no calls to the XMLHTTPRequest API (or window.eval).

Or you could be really conservative: only assume statelessness for pages without forms and without any Javascript. (These do exist!)

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

#280

Post by derefr »

brokenmachine wrote: post #278
derefr wrote: post #254

Earlier quoted context omitted.

Am I the only one who loves this behavior? I'd be perfectly happy forcing Chrome/Firefox/etc. into a 1GB sandbox and then telling it to "unload tabs on memory pressure." I only use a few tabs at a time; a simple LRU OOM-eviction algorithm should work wonders.

Maybe you're the only one. I hate waiting for a tab to reload from the network unnecessarily, especially on mobile!

"From the network" isn't actually a part of the semantics of this behavior, though. If the page's browser-side cache is still valid according to its original response headers, the browser will just reload the page from cache rather than hitting the network.
Post reply on HN