
20-line patch to Firefox 4 that makes startup on Windows 2x as fast - joshfraser
https://bugzilla.mozilla.org/show_bug.cgi?id=627591
======
ot
Taras Glek's blog (<http://blog.mozilla.com/tglek>) contains a lot more
information about link optimizations to improve startup times of Firefox.

One of the reasons why loading libxul is so slow normally is that the chain of
constructors called at initialization time is arranged _backwards_ in the
library ([http://blog.mozilla.com/tglek/2010/05/27/startup-backward-
co...](http://blog.mozilla.com/tglek/2010/05/27/startup-backward-
constructors/)) so the OS (which is usually optimized for forward loading)
cannot efficiently prefetch the pages.

There is also a post that explains how they measure the startup time on
Windows ([http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-
sta...](http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-startup/))
and Unix ([http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-
mea...](http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-
measurement/)).

------
blago
After using FF for 5 years it got so slow on my Mac that it became unusable. I
made the switch to Chrome last year and I'm not looking back. I was an early
adopter and supporter (including money) but FF is no longer what it used to
be. The code base is bloated, performance is sluggish, they don't seem to care
about developers anymore (websql anyone, lack of officially supported
debugging tool). All of this in spite of cream-of-the-crop tallent that they
have acquired in the last few years. I keep asking mysel and just can't
figure: how did it all go so wrong.

~~~
bzbarsky
> The code base is bloated

Evidence?

> performance is sluggish

In 3.6, right? 4.0 improves on a lot of that.

> websql

Which pretty much everyone developing web browsers and working on the relevant
standards now agrees was a bad idea, last I checked (if nothing else because
it can't be sanely standardized). Firefox 4 is shipping with IndexedDB, if you
note.

> they have acquired in the last few years

And who have been working on Firefox 4. Firefox 3.6 branched from trunk in
August 2009...

Yes, the release cycle is too long; that's being fixed.

~~~
1337p337
Well, bloat is somewhat subjective, so "evidence" is hard to come by. I don't
know about the other poster's reasons, but I agree, so here are mine. That
xulrunner/FF/thunderbird/etc. are built from the same tree is the first
indicator. Then there are the multitude of build options, a few pages' worth.
The output of these two commands is somewhat telling:

~/src/mozilla-1.9.2$ find -name \ _.c -o -name \_.cpp -o -name \ _.h -o -name
\_.idl -o -name \ _.js -o -name \_.xml | grep -v /tests/ | wc -l 11740
~/src/mozilla-1.9.2$ find -name \ _.c -o -name \_.cpp -o -name \ _.h -o -name
\_.idl -o -name \ _.js -o -name \_.xml | grep -v /tests/ | xargs cat | wc -l
4386362

(Painful to construct command lines like that on a phone, and that is a
somewhat old version of the tree, but unless FF4 is significantly smaller than
4m lines and doesn't require building xulrunner _and_ FF, the point stands.)
The large number of dependencies is another indicator.

I'd be remiss if I didn't mention that FF is still my "workhorse" browser, and
I like it a lot, despite the flaws and the bloat. (I've been using Arora for a
long time, but it has some stability issues still. I like Luakit, which is
small and hackable, but it's kind of a niche browser. I'm not at all a fan of
Chrome.)

~~~
andhow
> That xulrunner/FF/thunderbird/etc are built form the same tree > ... running
> wc -l on the codebase

These are your "bloat" indicators? That's about as primitive as using SLOC as
an indicator for programmer productivity.

~~~
1337p337
It's not a scientific metric; I did preface this by saying that "bloat" is a
subjective term. But LOC of the codebase is a pretty good rule-of-thumb
metric; I'm not pretending any more credibility than that. It's not hard
evidence, but it _is_ an indicator (and I chose the word carefully) that the
codebase may be trying to do more than it ought to. It is an indicator in the
same way that fatigue and a rash around your joints are indicators that you
have strep throat, but the evidence would be the presence of some strain of
streptococcus in your blood. There's no line of code that one can point to and
say "Hey, that conclusively proves bloat."

------
mbrubeck
(disclosure: I work for Mozilla)

The 2x improvement is for cold startup on specific configurations, mainly on
hard drives with slow seek times. For faster hard drives, the improvement is
less, and for SSDs it may be much less.

I should also note this is just one of many startup speed improvements coming
in Firefox 4.

~~~
kloc
There are lot of user with slow machines in developing nations. They are
typically using a pirated copy of windows xp on a slow hardware and since
initially microsoft didn't allow upgrade to IE 7 on pirated copies, lot of
people moved to firefox. They would certainly enjoy the fast startup time.And
considering that lot of such people are there( it was in the news that Ballmer
told Hu that 90 percent of China is using pirated windows) it is still a big
win for firefox usuability overall.

------
xpaulbettsx
Hmmm, so I suspect in practice that you're not going to see this kind of
difference usually - since he's probably testing on a binary he _just built_ ,
SuperFetch (the built in OS prefetcher) hasn't had a chance to determine what
pages are usually used by Firefox. Once you've used FF as your browser for
awhile, SuperFetch will know better and won't do as badly.

That being said, this trick will probably beat SuperFetch, since they know up
front that they'll be using big chunks of xul.dll. Don't do this in every app
though, or else every app in the system is just chewing through IOs on pages
they might not actually be using.

~~~
slightlyoff
SuperFetch only hits the first 10 meg of a DLL. If any of these are larger
than that, you'll still see significant thrashing on pages located further
back in the binaries. I implemented a similar solution for chrome.dll last
summer and it had a gigantic effect on cold start times. Glad to see Mozilla
prioritizing startup too.

~~~
asadotzler
Alex, can you link the bug(s) or patch set for your similar changes?

~~~
mihaip
<http://crbug.com/45510>, <http://crrev.com/50386>, <http://crrev.com/51486>,
<http://crrev.com/51594> and <http://crrev.com/54934> seem to be appropriate
links.

------
ck2
Pretty please put this in Firefox 3.6.15 as well because it will be quite some
time before many power-users can upgrade to 4.0

