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.
Multi-process Firefox brings 400-700% improvement in responsiveness
251–260 of 346 posts
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#252Earlier 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.
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#253Earlier 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…
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#254Earlier 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.
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#255Earlier 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.
Ref: https://labs.vmware.com/vmtj/memory-overcommitment-in-the-es... (search "page sharing")
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#256Earlier 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"?
Maybe it should be "00es"?
Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#257I 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 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
#258Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#259Re: Multi-process Firefox brings 400-700% improvement in responsiveness
#260Earlier 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 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.