Cold-start performance

High-level Feature Goals

• Reduce the amount of time it takes to launch Songbird, with an emphasis on:
• the first time the application was launched (from a cold start with no profile)
• measuring amount of time it takes to click the app to getting the license agreement screen drawn
• measuring amount of time it takes from downloading the last first run add-on to drawing the application on the screen
  
• launching the application with various library sizes (testing against libraries with 0k, 10k, and 100k media items)
• measuring amount of time it takes to click the application to drawing the application on the screen
  

Opportunities discussed for exploring improvements:

• reducing cold start, first run launch time
• being competitive with iTunes/Windows Media Player*
• reducing cold start, launch time with 10k or 100k of items in the library
• being competitive with iTunes/Windows Media Player*
  
• working on VLC startup load time
• working on getting the application on screen faster and playing around with continuing to load things even after the application is on screen in different orders
• improving the time it takes to load the application based on library size
• putting all libraries required to load at startup into a single DLL on windows
  

* Note: QA was asked on 6/10/2008 to provide a variety of benchmarks for Songbird, iTunes, Windows Media Player and Firefox 3.  This will take them a short bit to pull together.

QA Interface Points

We should provide capturable timestamps in the log so that QA can easily calculate the time it takes to get to various points in the startup. The start time will have to be recorded external to the application since we want to capture the full startup time. The following is the list of points I think we want to record:

• EULA dialog
• Add-On dialog
  
• Main UI
  

Optimization Tasks and Costs

The overriding goal is to get the user a usuable UI as soon as possible. Currently there are some tasks that can either be moved offline or better optimized to get the UI up and to the user quick. The following are the tasks involved in achieving this goal. Preliminary tests show cold start with no profile on Windows is around 30 seconds while Mac Os is around 12 seconds to get to the EULA screen.

Preliminary investigation shows that allowing modules like VLC to load asynchronously will likely get us our greatest increase in start up time. Windows seems the worse of the three platforms for cold start with no profile, possibly basing DLL's and/or consolidating may help the Windows platform.

The following area areas are the focus of the tasks that follow:

• Move some modules (VLC, gstreamer, etc) to load asynchronous or otherwise dely their loading.
• Reduce the time to load components by ether reducing the number of libraries or use techniques such as setting the base address.
• Speed up the UI responsiveness when working with large libraries.
  

The task list is now managed in the following Bugzilla stories

• Bug 10168 - Reduce cold start times
  
• Bug 10169 - Reduce start times with large libraries (>1000 songs)

The total cost for the two stories is 18 points. 7 Points are specific to the Story Bug 10169, the remainder will benefit both stories.

Investigation Results

Initial times for my machines have been recorded here in this Google Doc.

Also captured in that document are times for static builds. The gains were very small, so I moved Bug 10180 and Bug 10182 to P3. Combining the DLL's or setting the base address is not likely to get us all that much. Combining JavaScript modules might make a difference, but that turns out to be a fairly difficult task and I wasn't able to easily test to measure the difference.

One thing I discovered is that on Windows defragging seems to make a substantial difference in load times. It cut load times by at least half. It's possible that on systems that aren't defragged that combining or setting the base address may have a noticeable benefit. But at this time I think we should focus on changes that will benefit all users.

Delay loading VLC and other similar components based off coreBase JS object looks to gain us about 20% in initial startup time. In otherwords it looks like it will probably take between 1 and 2 seconds off.

For dealing with large libraries, using a copy on write scheme for the sbLocalDatabaseGUIDArray and sbLocalDatabaseAsyncGUIDArray classes should boost performance due to the numerous calls to the clone functions. I don't have any hard numbers for this other than it's called about 35 times during startup and several times per collection on average.