Closed Bug 468300 Opened 16 years ago Closed 15 years ago

Suggestion for Faster Startup: Chrome Dump

Categories

(Firefox :: General, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 512799

People

(Reporter: x.o_0.x, Unassigned)

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Firefox is generally a fast browser.  It loads pages far more quickly than IE, in my experience.  However, it is very slow to start up.  This is a major flaw that, if addressed, would, I believe, attract more people to FF.

I don't know all that much about how the browser works, but from my understanding the slow startup comes from the cross-platform XUL architecture.  I'm under the impression that, at startup, ff generates the chrome from the user's profile folder, then feeds that into Gecko, which renders the browser.  This is what makes startup so slow.  I propose, therefore, a solution that I call a "chrome dump."

Basically, the browser shifts the chrome generation from startup time to shutdown time.  When the browser shuts down, it generates the chrome from the user's profile folder and saves it (dumps it into) a JSON file, and saves it in the profile folder.  The json would contain, i'd guess, the DOM objects for one or more of the chrome documents, such as browser.xul, etc.  Then, when ff starts up, it simply executes the json using Gecko, quickly rendering the chrome.  I believe that it would work, although I could be wrong in thinking that all of the browser's settings could be represented w/in a json file.

Of course, there is one problem with this, which is it doesn't compensate for changes in the user's profile.  For example, if you, say, install an extension, there's no problem b/c the extension would be read when the browser was building the dump on shutdown.  On the other hand, when I'm synchronizing the portable firefox on my flash drive with the one on my main computer, i copy the profile folder from my home computer and overwrite the one on my flash drive with it, so the profile is changed between shutdown and startup.  Now, actually, in that case there would not be a problem b/c the chrome dump would be carried over from one folder to the other as well.  However, if one modified a profile more selectively, such as by using the FEBE add-on, then there would be descrepancy between the chrome dump and the actual profile.

The solution to this flaw, however, is quite simple.  FF would have to check for changes in the user's profile.  It could do this in one of two ways: firstly by looking to see if any files in the profile folder had been modified at a date/time later than the date/time of the chrome dump, or secondly, and probably using far more time and processing power, by generating a second chrome dump and comparing it with the saved one.  Of course, both of these tasks would take a while and so should not be done during startup.  Rather, once the browser has loaded the chrome dump, it would immediately perform this check.  Then, if it found a discrepancy, it would notify you with one of those bottom-right-hand-corner boxes saying something like "Your profile has been modified since the last shutdown.  Restart Firefox to apply these changes."  Of course, maybe that wouldn't work.  I don't know enough about ff's inner workings; it's possible that differences between the browser chrome and the external files in the profile could cause errors, in which case I guess ff would have to force shutdown if it found a change in the profile.  I don't know all the technical details of how my plan could be applied, I only have an idea for fixing the problem.

In short, ff's long startup time is perhaps its biggest obstacle, and I think it's something we should try to overcome.  And by we, I guess I mean you guys.  Not much i can do to help, at this point the only programming i really know is javascript and a little python.

Anyway, tell me if my idea is good, decent, or just plain stupid.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Not confirming, because not sure if this is good, but thanks for the idea.
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Keywords: perf
this is a basically a stab at whole-window-fastload, so duping against that bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.