On one of my previous posts, commenter Rasmussen wrote:
Umm, am just a dumb end user. Chrome is really tempting me now.. I stuck with FF while all my friends switched over to chrome solely because i’m addicted to addons and the Manifesto.
FF was the first software company that i discovered had an ideology, and it’s kinda exotic, because i always believed software companies were soulless.
I do hate the startup time and the crashes and as chrome has brought in the extensions, the case for me staying with FF is getting weaker.
However, Google is being evil sometimes, and the FF ideology charms me, and it could be the reason i’m typing this through FF, which is why i hope the bigwigs of FF are and will remain sincere about the ideology.
Hope you guys remain competitive, I do want you to win but just don’t become obsolete.
From my experience talking to and working with the “bigwigs of FF” as Rasmussen call them, I can personally vouch for their sincerity. They’re more serious about the Mozilla principles than most people I know are serious about anything. They’re dedicated to fighting for openness, freedom, and user choice on the Internet, and they know we can’t get complacent just because we’ve been gaining market share. They know that talking about our principles isn’t enough: we have to back them up with quality software that people want to use.
This isn’t the first time I’ve heard users complain about Firefox’s startup time and stability relative to Chrome. I could talk and talk about how seriously we’re taking those problems, how hard the Firefox team is working on performance and stability, and how killing crashes and reducing startup time are some of our highest priorities going in to Firefox 3.6 and 3.7. But maybe it will be more convincing to show you:
- The Crashkill project is aiming to identify and fix the most common causes of crashes.
- The Startup Time project is analyzing the reasons it takes Firefox as long as it does to start up, and finding ways to reduce that time.
- The Electrolysis project is moving plugins like Flash to a separate process, and extensions to another separate process, so that a problem with a Flash movie or an extension (both common causes of crashes) can’t take down the whole browser.
- Finally, see the Firefox Roadmap, which shows the top improvements planned for the next few releases.
Since Firefox is developed in the open, anyone can follow our progress. Firefox developers — who include not just Mozilla corporation employees, but also volunteers from all around the world — use the pages that I linked to above to track their own work on startup time and crashes. Since these pages are developer-oriented, they’re on the technical side. But whether you’re a developer or not, you’re welcome to use them to take a peek into what we’re doing.
Edited to add: Vlad has blogged a a good introduction to the problems involved in improving startup time. It’s still technical, but less so than the wiki page; check it out if you’re interested.
December 11, 2009 at 3:28 am
Jono,
Thanks for posting this. It’s amazing to see how passionate and enthusiastic people are for software. It’s important and critical to reaffirm Mozilla’s mission and dedication to the Firefox browser at a time when competition advances. Mozilla’s users and community thrive on lasting relationships through means of open communication and it’s great to see blog posts like this demonstrating that, yes, Mozilla does care.
- Aaron
December 11, 2009 at 5:50 am
[...] is the original post: What Firefox is doing about crashes and startup time « Not The … By admin | category: firefox | tags: firefox, heard-users, how-hard, startup-time, [...]
December 11, 2009 at 11:25 am
Here’s a comparative analysis of Safari, Chrome and Firefox startup:
https://bugzilla.mozilla.org/show_bug.cgi?id=533944
I’m the guy speeding up Firefox startup on the Mac.
December 11, 2009 at 12:46 pm
I’ve always felt that a good part of the sluggish performance of FF is due to XUL. It’s an amazing platform, but it’s not the fastest. Have you guys ever thought of using a different platform for FF or maybe redoing XUL from ground up?
December 11, 2009 at 3:20 pm
The killer on Mac is flash,
I get several crashes a week. Electrolysis
needs to come up as fast as possible.
I also run often
on a windows netbook where FF never crashes
but it does freeze an awful lot- screen
is greyed out for 5-10 seconds when changing
focus. A very low end machine, but chrome
remains responsive even on junk hardware.
December 11, 2009 at 3:56 pm
I’ll give Chrome startup time but I won’t give them stability. For a user like me who runs 50+ tabs regularly, Chrome screeches to a halt with each of its little processes eating away at my system with that many tabs open. I’ve had Firefox work (relatively) well with 250 tabs open.
But, I really do like how everything loads (cache?) so quickly right away on Chrome rather than crashing my router when I restore a session with ~25 tabs open.
But, I stick around for Weave
December 11, 2009 at 5:27 pm
@Fritz
Firefox 3.6 will have support for loading background tabs with lower priority than the active tab, which should help keep things from dying when restoring a bunch of tabs at once.
December 11, 2009 at 5:37 pm
Through your crashkill link, I could see that most of my crashes were from 3rd party, meaning Flash. Well, salvation for that is in hands of open video.
As for startup, I’m gonna hold my breath and watch the community work its magic. I couldn’t get a grip there
.
I could find that my worries are shared, and action being taken. Well, that’s nice.
“If you are not naughty, you don’t have to worry”- Eric Schmidt on CNN. The Chinese couldn’t have said it better. One more point for the manifesto.
Apropos,
I read a blog on the zine responding to the open-source revenue problems article in NYT, but that gave me no idea on how to make money from FOSS. Software industry is not my speed anyway.
Well, i hope you’re saving up a nice war chest, ’cause this browser war is as impressive as the Federer-Nadal rivalry. Federer has resolved never to lose a match because of lack of fitness, and money is the fitness of business, other things being equal, right?
December 11, 2009 at 6:28 pm
@Francisco
I’m not sure why you think that XUL is the cause of our slowness (perceived or not). It certainly isn’t, and it allows us to develop quickly on all the platforms we support (creating a UI once, and having it work everywhere is a big win).
December 11, 2009 at 8:15 pm
I’m really glad the Mozilla finally started working on startup time. I agree that the biggest temptation of Chrome is its excellent (cold) start time (at least for me). This is the sole reason why I find myself using Chrome nearly 1/3 of the time now. (Sooner or later something prompts me to start up Firefox every time, either because I need the functionality of an extension, or a Firefox quicksearch—quicksearches are more much flexible in Firefox, and I use lots of them, mainly for dictionaries. Or sometimes because Chrome’s content area is completely unresponsive on Windows when some other program is using 100% of the CPU, most likely because the priority of some of the Chrome processes is low.)
I really hope that Mozilla will manage to reach sufficient improvements in cold start time on Windows. (On Linux it’s not nearly as bad on my computer.)
About crashes: I got the (subjective) impression that Chrome crashes/misbehaves a but more often, but both browsers are very stable, and crashes are very, very rare here. At least for me, they are not at all a problem.
December 14, 2009 at 12:57 am
I looked over the Electrolysis overview and under Phase IV of Implementation it said “Run multiple content processes on-demand per tab/tabgroup/domain/whatever”.
Does this mean that it has not been decided if FF 4.0 will separate all tabs into processes or is there a ‘current thinking’ on this matter. I could understand that the per tab process approach could be expensive.
Is there anyone familiar with this that can speak to it?
December 14, 2009 at 9:06 pm
Hi Mark,
This isn’t my department so I’m not really the best person to ask (try asking #firefox on irc.mozilla.org instead), but as I understand it there is one major disadvantage to process-per-tab, and that is that a lot of data structures have to be duplicated into each process to support this, leading to a much bigger memory footprint. People are already complaining that Firefox uses too much memory. From the Test Pilot tabs study I know that there are people out there with 500+ tabs open. Do they really want what is essentially 500 copies of Firefox in memory at once? I don’t think so.
So I think the idea with Electrolysis is that we’ll get the platform to the point where it *can* split content into any number of processes, but *how we split*, and how many processes we split into, will be determined after some testing on realistic use cases.
October 7, 2010 at 9:46 am
useful plugins. thanks.