Fuck It, I'm Going Back to Firefox

Post by jtblin » Sat, Feb 14, 2015, 2:58 AM UTC

wooger wrote: post #525

spoiler wrote: post #505

Earlier quoted context omitted.

I actually have more problems with Firefox's performance than with Chrome's (in terms of processor power), Chrome definitely uses more memory, but it's super fast; firefox is just abysmally slow and can;t handle more than a few tabs. Tried both browsers on Windows 8.1 and Linux, with different machines (home and work computers), too. However, my high memory consumption in Chrome was due to using AdBlock, which is muc…

uBlock is now available on Firefox too, and makes an even more dramatic difference in performance. I really don't know what you're talking about - Chrome is a dog after ~10 tabs are opened, uses crazy memory and becomes unusable fast once it starts paging. Firefox remains stable, backgrounds tabs you're not using in a graceful way, and doesn't try to open and render every single tab at once on a session restore. It's…

Post by serge2k » Sat, Feb 14, 2015, 3:06 AM UTC

therealmarv wrote: post #491

higherpurpose wrote: post #326

Earlier quoted context omitted.

Actually my main problem with Firefox is that if it "chokes" on one tab, I can't use the whole browser until that fixes itself. In Chrome I generally have 20+ tabs open and I don't have any issues. Firefox needs to get itself a multi-process system. I really don't mind a little extra RAM being used as long as tabs are separated and sandboxed. I'm also looking forward to a complete rewrite in Rust. That should make Fi…

lol. You really think a new programming language will increase speed?! Rust is not faster as C++ for sure.

Post by zobzu » Sat, Feb 14, 2015, 3:08 AM UTC

dmix wrote: post #408

zetafunction wrote: post #333

Earlier quoted context omitted.

As a Chrome developer, I agree that process-per-tab absolutely should not be a replacement for fixing bugs. However, I think it's important to point out that process-per-tab is not just for stability: it's also critical for security.

Chrome is way ahead of Firefox in terms of security. It's worth the performance trade-offs. Each website is rendered in a separate process with a sandbox, each with an empty chroot + process namespace + network namespace + tiny seccomp-bpf + syscall whitelist. Chrome also has a stronger sandbox, pioneers better SSL, supports PIE on binaries, uses pepper - doesnt use native Flash plugins, the JIT compiler does randomi…

Post by zobzu » Sat, Feb 14, 2015, 3:16 AM UTC

jackmaney wrote: post #194

FilterJoe wrote: post #177

Earlier quoted context omitted.

The problem is using many open tabs with Chrome. If you use no more than 3 or 4 tabs, Chrome is generally fine. If you use more than that, Firefox has some built-in features to help with tabs such as delayed tab loading and tab grouping. It also has more and better extensions for helping with multiple tabs. Furthermore, it doesn't launch a new process for each tab. In a browser comparison I wrote last month, I includ…

I switched from Firefox to Chrome right around Firefox 3.6. I have an average of around 20 tabs open at any given moment, and I tend to go around a week or two between reboots. Other than the occasional tab crashing and quickly reloading (and by "occasional", I mean maybe once every couple of months or so), I've never had an issue with Chrome. It just works.

Post by frankzinger » Sat, Feb 14, 2015, 3:19 AM UTC

yellowapple wrote: post #421

muze wrote: post #312

Earlier quoted context omitted.

I don't think that's really fair, the largest Chrome task in memory isn't a tab or extension. Yes I suppose it isn't perfectly isolated and if something happens to the main program task it will obviously cause problems but if a single page or extension crashes everything else lives on.

It's a perfectly fair point. The fact that the largest Chrome task by far is not a tab or extension at all, but is the core of Chrome itself, indicates that maybe - just maybe - Chrome isn't doing as good a job of keeping things isolated as it should. That process shouldn't be doing a whole lot beyond driving the UI and managing the lifecycles of its children.