Closed Bug 503483 Opened 15 years ago Closed 13 years ago

Compile with --enable-faststart for Firefox by default

Categories

(Toolkit :: Startup and Profile System, defect, P1)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: deprecationmail, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [ts])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1) Gecko/20090624 Firefox/3.5

I suggest an option (off by default) which preloads all the Firefox components needed at startup, which means that starting Firefox through the click of an icon should lead to a small to no delay at all. Internet Explorer does this in Windows already, and I wouldn't mind a bit of extra startup time just to get Firefox to launch faster.

As I mentioned earlier, this should/could be off by default as the average user might not appreciate a longer startup time of the OS.

Reproducible: Always
Component: Shell Integration → Startup and Profile System
Product: Firefox → Toolkit
QA Contact: shell.integration → startup
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Whiteboard: [ts]
Depends on: 511984
This has been implemented, and now just needs to be enabled.

See bug 516516 for where in the build config to flip this on.
Priority: -- → P1
Summary: Preloading of Firefox components → Turn on --enable-faststart for Firefox by default
Severity: enhancement → normal
> I wouldn't mind a bit of extra startup time just to get Firefox to launch faster.

I hope this "feature" is optional.  I don't want more stuff bogging down my already sluggish system startup.

It isn't just Firefox slowing down my boot, it's firefox, adobe, quicktime, and many others (I've shut off as many as I've found).  It's only a win for me if a preload is done for the *one* application I'm going to use first, instead a preload is done for many applications, most of which I'm not going to use first.
If you read my post again, you'll see that I mention "off by default" twice. I'm not sure what Dietrich Ayala has in mind though, and I'm not sure if that applies to all OS's.
The name of the bug is "Turn on --enable-faststart for Firefox by default" so it's kind of a mixed signal.
Well, that wasn't the original name that I gave it. It was something like "Preloading of Firefox components", then Dietrich renamed it. I don't have a clue what "faststart" is, and that seems only to apply to Windows CE. Dietrich, is this really what I proposed in my first post?
--enable-faststart is the build-time option for enabling the preloading of components as you describe in comment #0. It's not specific to WinCE.
Summary: Turn on --enable-faststart for Firefox by default → Compile with --enable-faststart for Firefox by default
Fast start, as implemented, involves launching a binary at system boot and keeping it resident in memory, doesn't it? I'm not really keen on that. There's enough crapware that loads at system startup, I don't think we should contribute to that problem.
Crapware is in the eye of the beholder. If a user spends most of their time in Firefox, this is a benefit, not a problem. At the very least, we should offer the option.

Apple and Microsoft load infrastructure for their browsers at boot time in a similar manner. This doesn't greenlight our usage of this approach, but it's a point to consider when evaluating the viability of it.
In Mozilla Suite and SeaMonkey 1.x, we had a similar feature called "Quick Start" or "Turbo Mode" (mozilla.exe -turbo). When we removed it with the switch to the new Mozilla platform in SeaMonkey 2, a number of users complained, so they were most certainly used to having it. This may have been connected to the fact that this also offered a try icon with a context menu containing a few frequent commands like opening new windows/tabs, etc. but may also be connected to longer startup times without preloading most of the application at startup.
Does this offer a significant advantage on Windows Vista or 7 given the existence of SuperFetch?
(In reply to comment #6)
> --enable-faststart is the build-time option for enabling the preloading of
> components as you describe in comment #0. It's not specific to WinCE.

Dietrich, I guess I owe you an apology, as it may have sounded like I bashed you in my post. The latest comments describes exactly what I was looking for with my original post.

Starting Firefox on Windows, especially, is too slow. I think we can all agree on that. While that wouldn't justify us putting this in by default, the fact that, a web browser very often is the first application a user launch on their computer (we can have a poll about this soon, to confirm it), does.

Here are my two suggestions for keeping this "controlled":

1. It should only be activated if Mozilla Firefox is the standard browser on the computer. This way, we know that the user intends to launch Mozilla Firefox and not another browser.

2. The option to turn this off should be clearly visible in our settings.

------

Anything else?
Is it possible to activate this in the current Firefox trunk build? And if so, how?
Not everyone uses their PC for browsing. Every software company is so enthralled by their own product that they are blind to the fact that not everyone uses their product all the time. This blindness and also arrogance is why OS start-up times (you know, that's the thing EVERYONE uses for VARIOUS things) are so damned long. I am sick and tired of self-important software makers who force loading their oh-so-important product on start-up. For instance: The FIRST thing I do after EACH OpenOffice installation is to deactivate the friggin' auto-start. I'm glad OpenOffice makes it relatively easy (right-click on the auto-freaking-start tray icon and deselect it. But it's still an annoyance, and most users don't even know it's auto-starting at all. With most other programs, it's even worse (i.e. nearly impossible to deactivate auto-start).

Operating Systems should be allowed to load as QUICKLY AS POSSIBLE. Don't bog them down with self-importance. The default should be OFF. Please.

(OK, there was "some" ranting intertwined in that otherwise important message)
I know exactly what you mean Peter, and with most stuff (Adobe, Openoffice) I do the same thing. "Not everyone" surely isn't everyone, but might as well be 99%. That's why I'd like us to have a poll about it to see which behavior is the most common. I've heard people saying "and the first thing I do is hit the browser icon" many, many times.

Also, I am I'm no way working for Mozilla, nor are my (IRL) friends. Still, all of them want this feature.

-------

Another option is that we simply implement this and make it default to off, and then we gets some statistics on how many people who visited the settings and actually enabled this (and thinks this should be enabled by default).
Even for people who open the browser most of the time, there are still often times when a user doesn't need the browser during a session (e.g., to play a resource-hungry game, write a quick letter, quickly start up some music during a party). And starting up a program with the OS will make those tasks needlessly longer. The "total" start-up time for Firefox will still be the *same* (Firefox-in-OS + rest-of-Firefox = total time). It's cheating, plain and simple. There is no net gain.

So you either wait longer for your OS to start up *every time* (including when you don't need Firefox), or your OS starts up faster and Firefox loads at its actual time. The logic is that loading Firefox with the OS will yield an overall loss in time. It will *never* yield an overall win.
The thing is, that we don't even know if this will add a noticeable delay in startup time, but the benefit when starting the browser could be huge.

Would you agree though, that we should offer this as an option (off by default), at least?
(In reply to comment #15)

Thanks Peter. You've made your opinion clear, and provided some scenarios worthy of consideration. Be sure that if this feature is ever turned on by default, you'll be able to turn it off easily.

However, you use words like "often" when you describe how users generally use their OS. Please provide evidence if you have it. Making anecdotal generalizations doesn't make a strong argument.

We need to find (or conduct) research on how often users reboot, how much time the browser is open vs not during an OS session. We'll also need to measure, if possible, how much time this adds to OS boot time.
jono,jinghua, is there anything in the recent studies that would tell us about the session/reboot info needed here?   we should add that to the next "day in the life of the browser" study.
Jesse suggested only fast-starting firefox if it was used in the previous OS session. We could fast-start only if it was open within a certain window of time before shutdown, even.
He also suggested having the fast-start component exit in low-resource conditions. Eg: someone opens Photoshop, playing a game, etc.
Group,
There have been some very differing viewpoints in this discussion, and all have their merits.  From another non-coding user's perspective, perhaps there is a way to dynamically control the fast-starting background services based on the actual usage of a user's system in real time?  What I mean by this is:
1. At system boot, only start a "monitoring" service (very low memory usage and effect on system startup performance)

2. Develop rules for fast-starting based on real-time system conditions (could even make them user-configurable).  For instance, if CPU usage is <20% for 5 minutes, run fast-start procedures.  Once fast-starting is loaded, if Firefox is not started in 10 minutes, unload fast-started services from memory and return to Rule #1.

3. Display a tray icon when fast-starting is running.  Remove from tray when not running.  Perhaps the tray icon could point to a Firefox settings page where the user could configure the rules or disable the tray icon altogether (once a user knows its there and where to go to configure it, they probably don't need to be notified of it anymore).

4. Once Firefox has been started by the user, perhaps we unload fast-starting entirely until the system is rebooted?  Does warm-start versus cold-start data indicate a win if we keep fast-starting enabled after the browser is run?

Instead of debating over "to be, or not to be" fast-starting completely, let's take a more minimalistic approach and provide the users the choice in a meaningful way.

Thank you for your time and hard work.  You are all contributing to this excellent product and I, as do many others, appreciate it.
these are additional changes to allow faststart to work w/ non-WinCE Windows OSes. requesting review from Dolske since he worked on the original patch for Firefox support.
Assignee: nobody → dietrich
Attachment #423493 - Flags: review?(dolske)
Attachment #423493 - Attachment description: changes required to support winxp → changes required to support non-WinCE Windows
With an empty profile, I tested post-boot cold startup and found that the faststart functionality gives >60% improvement.
Comment on attachment 423493 [details] [diff] [review]
changes required to support non-WinCE Windows

Justin: note that this is a first set of changes, that can be checked-in independently since they're just required to get the build/packaging working properly for non-WinCE. a subsequent patch will need to make changes to the installer and updater, to get it actually running.
(In reply to comment #15)
> starting up a program with the OS will make [other non-Firefox] tasks
> needlessly longer. The "total" start-up time for Firefox will still be the
> *same* (Firefox-in-OS + rest-of-Firefox = total time).
>
> So you either wait longer for your OS to start up *every time* (including when
> you don't need Firefox), or your OS starts up faster and Firefox loads at its
> actual time. The logic is that loading Firefox with the OS will yield an
> overall loss in time. It will *never* yield an overall win.

(In reply to comment #17)
> You've [...] provided some scenarios worthy of consideration. 

I don't see any evidence of this "consideration" (with the exception of the unlikely to ever be implemented suggestions in comment #24).

> Be sure that if this feature is ever turned on by
> default, you'll be able to turn it off easily.

What *I* can do is irrelevant (or am *I* the target for all Firefox development?). Of course *I* can turn it off. *I* can also register a bugzilla account. Most users will not even known it's there, let alone know how to turn off this despicable cheat at the expense of all other activities. Also, people typically don't change the default settings. The realistic result will be that the vast majority of users will have yet another program loading during OS startup. And their OS startup times will be negatively impacted forever.

(In reply to comment #24)
> With an empty profile, I tested post-boot cold startup and found that the
> faststart functionality gives >60% improvement.

That is a highly misleading claim. Why not just put Firefox in the AutoStart and claim a 100% "improvement"? Much more relevant questions are:

1. What is the impact on OS startup? (in seconds!)

2. How many seconds faster does Firefox startup (after the OS + PartOfFirefox have already loaded)?

3. How many seconds longer does the OS + PartOfFirefox take (than OS alone)? 

4. Is there a net gain or a net loss in total Firefox startup time?

5. How much net gain/loss is enough to justify negatively impacting all other non-Firefox activities?

I look forward to some actual and serious "consideration".
Peter, stop fooling around and realize that we are speaking of the average person here. I can only speak for the 50+ people I know closely, none of which are interested in the browser, or knows anything about background-processes. Still, the first thing they press is their web browser icon.

That's democracy for you. If you are one in a thousand, who doesn't like this change, then we would still go through with it, considering the other 999 people wants it. I got to repeat that, we should have a poll about this.

I'd also like to suggest, if I haven't already, that we make this a clearly visible option in Firefox.next (3.6.x/3.7?), where it can be enabled easily (with a short description of what it does), but is disabled by default.

I agree on one thing with Peter though, and that is that the impact on OS startup in seconds is interesting and should be investigated before this gets enabled by default.
To make it clear, what I am saying:

Our next goal should be to get this pushed to the trunk, having the option only visible in about:config for now.

Our next goal should be to have this as an actual UI option, with a description of what impact it could have etc.

And finally, we could consider if this should ever be enabled by default.

And there we have it, we can now stop this debate until we've finished the two first steps.
(In reply to comment #26)
> > The logic is that loading Firefox with the OS will yield an
> > overall loss in time. It will *never* yield an overall win.

It's possible that loading the core binaries at boot time might take less time than loading them when the user is fully logged-in and Firefox startup is contending with other resources (other applications). However, that's not the major win claimed here, and has never even been described that way.

This is about trading time that is more important to the user (wanting the browser to load) for time that is less important to the user (waiting for the computer to boot, where a wait is expected). And that, only *if* the research bears that idea out.

> (In reply to comment #17)
> > You've [...] provided some scenarios worthy of consideration. 
> 
> I don't see any evidence of this "consideration" (with the exception of the
> unlikely to ever be implemented suggestions in comment #24).

Some of those suggestions are already implemented (or partially so) in the faststart service.

> (In reply to comment #24)
> > With an empty profile, I tested post-boot cold startup and found that the
> > faststart functionality gives >60% improvement.
> 
> That is a highly misleading claim.

I measured Firefox startup time post-boot with and without the faststart service. I plan on doing more research, but just got it actually working last night and posted the initial result to see how much of a difference it actually made. If it was small, then there'd be no point in continuing to look at this.

If you want to help, please hop in and do some of this research. As you suggested, you could just put Firefox in autostart and measure that, to answer some of the questions you posed.
(In reply to comment #28)
> To make it clear, what I am saying:
> 
> Our next goal should be to get this pushed to the trunk, having the option only
> visible in about:config for now.

Exactly. We need to get it to the point where nightly testers can experiment, and then get their feedback. We'll have data from a variety of Windows configurations then. Ideally there'd be a way to measure built-in. Maybe I can get bug 522375 fixed beforehand.
Comment on attachment 423493 [details] [diff] [review]
changes required to support non-WinCE Windows

As I (coincidentally) just noted in bug 511984 comment 15, I've only actually tested this on WinCE. So, while the build changes look fine to me, I'm assuming you've done the testing to verify this stuff actually works on non-WinCE Windows. :)
Attachment #423493 - Flags: review?(dolske) → review+
Comment on attachment 423494 [details] [diff] [review]
turn on faststart by default

I don't think we should enable-by-default in this way... Better to add --enable-faststart in the releng mozconfigs? I don't think most developers will want their builds enabled this way, because faststart doesn't help when you're recompiling during development.

Before enabling this, we'll need to understand the impact might have on releng... I'd worry that our various test and perf suites are likely not expecting to have the process pre-exist and persisting across runs. And then there's the matter of what we want Ts to measure.

Also, we need to be sensitive to reaction from users if/when we ship this in an alpha or beta... It's pretty clear that this will upset some people -- some on ideological grounds, some due to issues that we can address (eg comment 19 and comment 20). I don't feel strongly either way about enabling this, but I am sympathetic to the concern that lots of apps have implemented this kind of thing in the past -- poorly -- leading to a knee-jerk "hell no!" reaction.
Attachment #423494 - Flags: review-
Justin, after much thinking I've actually started to change my mind. Perhaps the furthest we should go with this is to have an UI option. There is a lot of people writing about "the slow start of Firefox" in forums and comments and so on. The people who knows about this option might refer them to this setting, and have them enable it.

Still, I think we should get this checked in to the trunk, with an about:config option (set to false, of course) as soon as possible. Having it in there does not affect developers/users in any way, if they just keep it disabled. We can then get feedback from the people who enable it and fix issues that might appear, and finally, put in a UI option if the win in time is large enough.
Hope in the near future we can have it activated in about:config and so it can be used in Windows XP? i'll activate it first :-),If Microsoft is cheating with this option this is...i don't even start iexplore lol...

Thanks.
Blocks: FF2SM
Version: unspecified → Trunk
Blocks: 447581
I am an XP user with a rather large memory (1 GO.) so I think that FF will stay in memory (if loaded at start up of XP) till I use it. I use FF probably in 75 % of my XP sessions (not always at its beginning) so loading it uselessly is not a big deal.

By principle I hate installers that preload without saying it and I undo this setting except when the program is used in a high % of my sessions.

But the preload should be as fast as possible that means that the files preloaded should be defragmented at installation or update time. There is at 
http://technet.microsoft.com/fr-fr/sysinternals/bb897428.aspx
a freeware contig that defrag a file.
Think also to defragment at installation or update time the huge (>42MO.)  urlclassifier3.sqlite or any other big files. Think to have this file only once in the system and not in each profile (not so easy to program but this will speed up its update) : my anti-virus is able to have only one signature database system wide !

Think also to speed up launching Thunderbird !
Please don't spam bugs with various issues. This bus is about a *compile* time issue which might or might not be used by the various applications (it's not about a browser or mailer in specific).

Note 1 : Defragmenting files has nothing to do with this (and urlclassidier3.sqlite isn't read at startup anyway, especially not the complete file, so it won't help at all). the file will be vacuumed though, which is a totally different issue.
Note 2 : using only a single file for all users has other issues (who is going to update ?). An anti-virus utility is *not* installed by a user.
unassigned, not working on this right now. i'd love to see someone get this landed, off by default, with an easy way to turn it on so we can get some actual user feedback.
Assignee: dietrich → nobody
Depends on: 652445
Is this something we actually want? Because it got removed in bug 652445
This:
- Only ever worked on WinCE
- Was partially removed already in bug 651622
- Now fully removed by bug 652445
- The ideas here likely to be made redundant by bug 627591 (windows) and bug 632404 (linux)
- Was looking like it was already heading towards WONTFIX

-> WONTFIX, unless someone speaks up now?
(In reply to comment #40)
> -> WONTFIX, unless someone speaks up now?

In fact, to save me having to remember to do this later, WONTFIXing now; given that it's fairly trivial for someone to reopen later, if the points in comment 40 are deemed insufficient. Thanks! :-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
No longer blocks: FF2SM
You need to log in before you can comment on or make changes to this bug.