Live data from Hacker News

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

techcrunch.com

251–260 of 346 posts

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

#251
post #165
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'…

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.

It is frustrating that Firefox makes it so easy to delete recent history, but difficult to remove old stuff. I really only want the last month or so; why do I have to clear it manually?

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

#252

Earlier quoted context omitted.

I'm saying that the performance of today's firefox on 2006 hardware is better than the performance of 2012's firefox on 2002 hardware. I consider that to be a better measure than to compare both releases on 2006 hardware.

Thanks for clarifying. If you know anyone willing to donate 2002 era hardware, I'd be willing to do some tests and benchmarks.

I used a 2006 laptop until the beginning of this year and prior to that has a 2000 desktop. Can confirm.

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

#253
post #78

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.

The main reason tabs aren't saved to disk isn't a concern about responsiveness, it is a concern about data loss. You have to be very sure that you restore the state exactly. What if you spent a few hours filling out some government form online, then you went and took a break by watching a few YouTube videos? Memory usage might spike up, and the browser decides to unload the tab with the form. You'd be mad if form sta…

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

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

#254
post #162

Earlier quoted context omitted.

FF mobile does this and it drives me nuts. I'll be on 4chan, watch a YT clip, then tab back and FF reloads the original HTML. Apart from being slow (takes a few seconds to rerender it all), it also loses AJAX-loaded data. My phone reports it has 600MB of RAM free, so I dunno what's causing FF's behaviour here nor how to disable it. I can't always reproduce it, but it happens enough that every browsing session has som…

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.

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

#255
post #44
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.

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: https://labs.vmware.com/vmtj/memory-overcommitment-in-the-es... (search "page sharing")

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

#256
post #159
post #151

Earlier quoted context omitted.

Hardware does not get exponetially better. Maybe it did in 90ties and 00ers. Right now hardwardware gets slimmer, less power consuming and cheaper. But not better. My 12 year old (then mid-end gaming pc) is pretty much exactly as fast as my current, 2(?) year old office machine. (x264 and other mulit-threaed cpu benchbmarks) But it costs a fraction and uses next to no energy. /edit: Yes this is wrong. I made a mistak…

Love the redundancy of "90ties", but what's the etymology of "00ers"?

I pronounce "00ers" as "zeroes"

Maybe it should be "00es"?

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

#257
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'…

I can't find any other reports of it, but I was on FF 47.0.1 on Windows 7 and upgraded to 48.0.1 (For some reason I never upgrade when prompted on the XX.0 releases). And I would have intermittent whole-browser freezes that lasted about a minute. Not like one every 4 hours, but more like once every 5~10 minutes. Back down to 47.0.1.

I tried again on 48.0.2, ... same thing.

I can't nail it down specifically enough to file a proper issue report, so I guess I'll keep trying when the next releases come out.

I also notice that webapps seem to like Chrome better, but FF usually performs "well enough" that I've put up with it because I find it (for me) to be markedly better at helping me deal with the ginormous amounts of text content I apparently consume. But webapps have been degraded enough for the last month-or-so that I'm running chrome in parallel just for those.

I love FF and I'm hoping that this is one of those isolated things that the fabulous team over there fixes before too long. (I suspect it's a JS related something or other, but I haven't been able to track it down specifically.)

(Wow. Now there is a rambling comment!)

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

#259
I use both FF and Chrome. Chrome is more heavy-duty, so I use it for Dedicated Browsing. I've set it such that when something calls me away and I close Chrome, the tabs will reopen so I can continue where I left off. But sometimes I'll be doing something in another program and need to look up something quickly. In such cases, I don't wanna wait while Chrome reopens 11 tabs so I'll use FF instead. My FF-tabs aren't saved between sessions, so I only see a single fresh tab when I open it.

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

#260
post #175

Earlier quoted context omitted.

Servo is "just" a new rendering engine, though, not a whole browser.

Well, it is for now. This isn't yet a concrete plan that Mozilla has, but from what I've read, the Servo developers would definitely also like to write a JavaScript-engine in Rust, simply because of the gain in security. Also, browser.html already exists in an early form (and is bundled with Servo). It provides a new UI written in HTML, CSS and JavaScript, so it can be rendered by Servo as well. https://github.com/br…

> Servo developers would definitely also like to write a JavaScript-engine in Rust, simply because of the gain in security.

(Servo developer here)

This isn't really the case. There is interest in doing this, but it's not something we definitely want to do. The problem with writing a new JS engine is that you need to duplicate years of performance tuning so while it might be safe, it would take immense amounts of work to make it efficient. Rust's safety benefits get reduced when you have JITs and all involved, too.

It would be nice to have, sure, but the amount of work in making a usable one is huge.

Post reply on HN