Startup I/O: how do 3.6 and 4.0 compare?
During the past weeks, I've been posting a lot of data about what various changes can bring in terms of startup time improvement. It is now time to look back on how thing have changed between 3.6 and the upcoming 4.0.
With the same setup I've been using in the past, and the same modus operandi, with a fresh profile:
| 3.6.14pre | 4.0b8 | Difference | |
|---|---|---|---|
| x86 | 2,933.46 ± 0.72% | 3,228.76 ± 0.57% | 295.30 (+10.06%) |
| x86-64 | 3,150.5 ± 0.59% | 3,382.0 ± 0.51% | 231.5 (+7.34%) |
So, 4.0b8 ends up being slightly slower than the latest 3.6 on startup with a fresh profile. Now that relocation packing landed, we should be closer to 3.6, but still slightly slower.
On the other hand, 4.0 has seen two main changes directly impacting on startup time:
- omni.jar: most chrome, preferences, javascript modules, and components are now all packed in a single file in the Firefox directory.
- packed extensions: most extensions are not unpacked anymore in the profile directory,
Let's thus see how each of these is making a difference, starting with omni.jar:
| 4.0b8 without omni.jar | 4.0b8 | Difference | |
|---|---|---|---|
| x86 | 3,420.4 ± 0.92% | 3,228.76 ± 0.57% | 191.64 (-5.60%) |
| x86-64 | 3,554.22 ± 0.82% | 3,382.0 ± 0.51% | 172.22 (-4.85%) |
As can be seen here, packing most files in the Firefox directory did bring roughly a 5% speedup on cold startup, which helped keeping 4.0b8 somehow close to 3.6 in startup time on fresh profiles.
| 3.6.14pre with extensions | 4.0b8 with extensions | Difference |
|---|---|---|
| 4,457.18 ± 1.79% | 4,235.14 ± 0.60% | 222.04 (-4.98%) |
Taking six of the most popular extensions that work in both 3.6 and 4.0, we can see the positive effect of keeping extensions packed, especially considering a fresh profile is slower with 4.0. It has to be noted, though, that one of these extensions enforced being unpacked (which is still a possibility for extensions requiring it), so the 4.0 profile had effectively five packed extensions and another unpacked one.
2011-02-08 11:49:33+0900
You can leave a response, or trackback from your own site.
2011-02-08 14:22:49+0900
Wow, so much effort and communication around performance for Firefox 4, but the result on your hardware and OS is not very inspiring :-/
I hope the next release will reduce startup time. I’m not that concerned about it personnally, but I see so many people leaving Fx for Chrome just for the (perceived) startup time.
2011-02-08 14:59:34+0900
@Stiph
I imagine that of those complaining of bad start up times, many were experiencing particularly noticeable delays. Like the font-reading issue or badly-behaving extensions: delaying start-up by an order of magnitude more than the 3s typical above.
2011-02-08 16:02:13+0900
I have to concur with Stiph. This is fundamentally incredibly disappointing. All the positive posts about omnijar and so forth have completely sucked me in. Damn you Mozilla, I hate being deceived. I’m a cynic but even I got sucked in. I’m starting to wonder why I even bother reading Planet Mozilla daily.
Where was this kind of analysis when we were being presented with all the blog spin about speed improvements?
From now on I will not believe any metric that spews forth from Planet Mozilla unless it is accompanied by progressive comparison such as that found in this post.
What code is responsible for slowing down the start up time to the point where (apparently) substantial improvements have barely kept pace with compensating for the bloat?
This is such typical Mozilla when it comes to Firefox: all spin and no reality. I’m sick of it. I’ve had a gutful! It’s time to face the truth: Firefox is a performance laggard and seemingly always will be. I’ll keep using it because I have no real choice but I’m disgruntled to say the least. Lucky I do not work for the post office!
2011-02-08 16:10:55+0900
pd: my guess is that e.g. webgl and webm support increasing the binary size, they mechanically increase the overall I/O problem with static initializers and others. On the other hand, 4.0 with extensions *is* faster than 3.6 with the same extensions.
2011-02-08 17:12:19+0900
@pd: First, great attitude, dude.
Second, you’re overlooking the work done to speed up loading Firefox with open tabs, with a dirty profile, …
2011-02-08 23:14:42+0900
Starwed: you may be right. But if so, what’s been the point of all this low-level hacking involving disk I/O and the like? I too was under the impression that startup with a clean profile had been improving.
2011-02-09 11:33:00+0900
njn: The biggest game changers haven’t landed, unfortunately.
2011-02-09 22:31:03+0900
It still might be interesting to dig into what caused the increases between 3.6 and 4.0 in the first place. We also found a number of memory increases earlier in 4.0 development and subsequently could identify most reasons and work on them so that a lot of problems could be fixed again for 4.0 final. Might make sense to so something similar wrt those things.
2011-02-11 20:22:47+0900
@Andy
My attitude is one of impatience. I imagine it’s one shared about about 10% of other web users. You know, the ones that have migrated from Firefox to Chrome in such a short period of time. The very same set of users that is forcing Mozilla to copy several elements of Chrome (at least in UI terms) just to “appeal to mainstream users”.
I’m not overlooking anything. I commented on the evidence in front of me at the time. The evidence in this post. Your comment and the content of this article have no reference to dirty profile data.
Regardless I expect that what you suggest represents two problems: Planet Mozilla articles almost never focus on the bigger picture and reference that context fully in articles such as this. Secondly people such as yourself often throw in some other metric or solution to an issue and these are generally excuses.
I’d love to see a research study on how often certain topics are talked about within Mozilla blog circles, for how many years, that fail to address the concept at hand globally on a consistent, realistic and quantitative way across multiple Firefox versions. It just does not happen! This is what I’m unhappy about as much as the poor performance of startup.
Startup performance should be considered in at least the following contexts: number of opened tabs in restored session; size of those tabs; clean and ‘dirty profiles; cold and warm booting; processor and memory speed; number of extensions installed; total and type of other applications opened first; impact of common third-party software such as Windows Prefetch and various anti-virus tools; speed perception (the old splash screen debate); tab content loading (necko influence) …
@glandium thanks for the feedback. Thanks for these artciles. They do giive an insight that Firefox supporters like me may not otherwise get. I just wish your articles and that of others on the same topic could be more comprehensive. It’s natural human nature to hope for the best and spin results positively but being scientifically objective is best for keeping things in perspective I think.