Introduction
Startup is important because it is the first interaction that your user has with your application. You get one chance to impress, and failure to do so could mean the user closing and/or uninstalling your application permanently. What follows is a set of tips and tricks you can use to supercharge the startup path of your Silverlight application.
The Cardinal Rule
There is, essentially, a single cardinal rule.
Do the absolute minimum required to display your main screen.
Write this on a sticky note and hang it on your monitor. This may seem like common sense (I like to think so), but I’ve analyzed many an application that violates this rule in more ways than one. The less deterministic the code is that you’re executing, the more you’re asking for trouble. To subdivide this rule into some specific examples:
Minimize your download size.
Never wait on network I/O before displaying your main screen.
Minimize disk I/O, delay-load any data or business logic that you can.
Minimize your download size
Since your application has to be downloaded before it can start up, your download size directly affects startup time. Consider dividing your application into multiple XAP files. The first XAP should include only what is necessary to display your main screen and provide core functionality. Tim Heuer has put together a great video on silverlight.net titled “Loading Dynamic XAPs and Assemblies” that explains this concept in detail. Use this method to componentize and delay load parts of your application that pull in large dependencies and/or don’t absolutely need to be available when your application starts up.
Another great tip on Silverlight XAP compression comes from David Anson. A Silverlight XAP is just a renamed Zip file, but as of Silverlight 4 our XAP compression algorithm isn’t as efficient as it could be. By simply re-zipping your XAP files using an optimal compression algorithm you can shave about 20% off your download size (as high as 70% in extreme cases). Check out David’s post, “Smaller is better!” for the details and a useful script to help you automate the process.
Never wait on network I/O
No-doubt, this is one of the riskiest things you can do during startup. Network I/O latency is non-deterministic; when you make a call to a web service or access data from a network share your request could return in 2 milliseconds, 2 seconds, 2 minutes, or it may never return at all! If your application waits for this data to be retrieved before showing your UI, it may never show up. At best, you are gambling on the speed of your network connection to determine your startup time.
Minimize disk I/O
When you increase the amount of data that you load from disk (whether raw data files or loading unnecessary assemblies) you increase the amount of time that you’re waiting for physical media. It takes a substantial amount of time for your hard disk to seek to each new read location, and it takes time to read the data once you seek there.
Read more: Silverlight Performance Blog
Startup is important because it is the first interaction that your user has with your application. You get one chance to impress, and failure to do so could mean the user closing and/or uninstalling your application permanently. What follows is a set of tips and tricks you can use to supercharge the startup path of your Silverlight application.
The Cardinal Rule
There is, essentially, a single cardinal rule.
Do the absolute minimum required to display your main screen.
Write this on a sticky note and hang it on your monitor. This may seem like common sense (I like to think so), but I’ve analyzed many an application that violates this rule in more ways than one. The less deterministic the code is that you’re executing, the more you’re asking for trouble. To subdivide this rule into some specific examples:
Minimize your download size.
Never wait on network I/O before displaying your main screen.
Minimize disk I/O, delay-load any data or business logic that you can.
Minimize your download size
Since your application has to be downloaded before it can start up, your download size directly affects startup time. Consider dividing your application into multiple XAP files. The first XAP should include only what is necessary to display your main screen and provide core functionality. Tim Heuer has put together a great video on silverlight.net titled “Loading Dynamic XAPs and Assemblies” that explains this concept in detail. Use this method to componentize and delay load parts of your application that pull in large dependencies and/or don’t absolutely need to be available when your application starts up.
Another great tip on Silverlight XAP compression comes from David Anson. A Silverlight XAP is just a renamed Zip file, but as of Silverlight 4 our XAP compression algorithm isn’t as efficient as it could be. By simply re-zipping your XAP files using an optimal compression algorithm you can shave about 20% off your download size (as high as 70% in extreme cases). Check out David’s post, “Smaller is better!” for the details and a useful script to help you automate the process.
Never wait on network I/O
No-doubt, this is one of the riskiest things you can do during startup. Network I/O latency is non-deterministic; when you make a call to a web service or access data from a network share your request could return in 2 milliseconds, 2 seconds, 2 minutes, or it may never return at all! If your application waits for this data to be retrieved before showing your UI, it may never show up. At best, you are gambling on the speed of your network connection to determine your startup time.
Minimize disk I/O
When you increase the amount of data that you load from disk (whether raw data files or loading unnecessary assemblies) you increase the amount of time that you’re waiting for physical media. It takes a substantial amount of time for your hard disk to seek to each new read location, and it takes time to read the data once you seek there.
Read more: Silverlight Performance Blog