20-line patch to Firefox 4 that makes startup on Windows 2x as fast
bugzilla.mozilla.org
bugzilla.mozilla.org
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...) 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...) and Unix (http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-mea...).
It's true, without SSD, FF3.X cold-start is not what it should be. However, many users do face an interesting dilema. They complain about slow startup time, and at the same time, call themselfs power-users with 10+ extensions, which makes it hard to switch browsers.
The recent Skype-disaster highlighted the problem of missing extension-benchmarks for the public. I don't know how that could be done, but besides the 5-star ratings, there could be a mozilla-provided performance indicator.
FF4 does improve performance, but power-users will still use the same extensions.
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.
~/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.)
These are your "bloat" indicators? That's about as primitive as using SLOC as an indicator for programmer productivity.
xulrunner and Firefox are (since Firefox is a strict superset of xulrunner). Thunderbird pulls in the core code and has a separate tree for the mail-specific stuff.
The line of code count is what it is, but what makes that "bloated"? Have you compared that to any other reasonably full-featured web browser (e.g. not links)? Have you compared the dependencies to any other web browser? I think you're just severely underestimating how much stuff a web browser is expected to do nowadays...
Most of the build options are dead, in fact (as in, if you try to use them, they won't build). There's ongoing work to remove them from the configure script so as not to confuse people.
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.
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.
http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...
Yuck. Is there a good engineering reason for this reliance on the physical location of code within a lib file rather than its logical internal structure? I guess its a compromise they made after running some studies. Still seems sickeningly ugly though. Just like the trick the OP was forced to implement to override this behaviour.
Yucketty yuck yuck.
I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.
All I meant by 'yuck' was that in my limited experience with computer science, whenever there is a solution that involves as blunt a compromise as 'cache the first 10 megabytes,' it isn't usually too long before that solution is known as the 'naive' solution.
If you could tell me if that's causal, it'd be awesome = )