sdwilsh Status Update: 2010-08-29
Done:
- At least ten reviews, mostly for the developer tools group. Some day I'll list the reviews I do in these updates, but today is not that day
- Hacked a bit on compare-talos (file issues if you find bugs or want a feature!) to make it more useful for the next item
- Fixed bug 583611 (blocker)
- Fixed a pymake bustage so people on windows could build with it again
- Created a patch which got checked in (albeit with a poor commit message) to fix an issue where the implementation didn't do what the docs said in docshell code for bug 587573 (blocker)
- Fixed bug 590654 (blocker)
- Fixed bug 519769 (blocked bug 583882)
- Fixed bug 583882 (blocker)
Next:
- Blog posts on results from most recent data collection for goal.
- Blockers
- Reviews
sdwilsh Status Update: 2010-08-20
Done:
Got diverted this week to help identify a performance regression for mak. Bunch of stuff will be carried over to next week as a result.
- A small number of reviews
Next:
- Get through my ever-growing review queue (or at least shrink it)
- Created a patch to backout bug 178506, which landed back in January, because new data came to light making it a Very Bad Idea. Landed it and now a bunch of people hate me.
- Hacked a bit on compare-talos (file issues if you find bugs or want a feature!) to make it more useful for the next item.
- Identified the cause of a Ts regression when we tried to enable WAL for places in bug 573492.
- Created a plan on how to move forward in bug 573492 for mak's input when he gets back from vacation.
Startup Time in the Wild Take Two
This week, I spent some time looking at some real life profiles that were sent into us by users seeing startup time in the minutes. The tests were ran just like I ran the test on my profile: all add-ons disabled. The results I got are both good and bad, but first the results!
Results
The first shows the raw test run data (which isn’t terribly interesting). The second compares the reported startup time for each test. You will probably want to click to zoom in.
Conclusions
Like I said, the results are both good and bad. Good in that I now have a pretty good idea on why people have bad startup times. Bad in that we don’t have any way to quickly improve the issues that people are seeing. What I see from this data is that profiles in the wild, with add-ons disabled aren’t much slower than a clean profile. This seems to implicate add-ons being at least part of the problem (which we knew) or possibly all of the problem at this point (for the profiles tested). The good news is that the add-ons team is already working on solutions to this, and you should expect some blog posts from them about this soon.
Next Step
Next week I’m going to spend some time getting numbers with these profiles on the latest release of Firefox 3.6 with and without add-ons disabled to compare. This will pretty much confirm or deny my hypothesis of this week’s results.
News on the Past
In my last post, we looked at my profile with various pieces removed to try and figure out why startup might be slow for people. With those results, I identified two issues that would impact startup the most:
- Large cookies.sqlite
- Many tabs being restored
I also have good news about both of these issues! The cookies.sqlite issue is now fixed and will be a part of beta 4, and Paul has some good data about session restore and tabs (with more to come).
sdwilsh Status Update: 2010-08-13
Done:
- A few reviews (not many this week!)
- Blog post with more "dirty" profile goal stuff.
- Fixed blocker bug 581000
- Sheriff duty
- Discussions on IndexedDB in public-webapps
Next:
- Fix blockers
- Collect more data for "dirty" startup goal.
Bugzilla Helper 0.4.2 Released
You can go grab it on AMO or wait for Thunderbird to tell you to update. This contains a one-line work around that makes the add-on work after the semi-recent change in the API. You can read all the fun details over in bug 586032.