There are 2 issues here.
- Initial download time and
- Actual runtime performance
Download time/app size:
Monolithic applications (many many megs of initial download) result in a poor user experience. This is the most common problem everyone hits in Siverlight if they create a single large applications (basically the easy approach). You may produce an application that takes minutes to load. The guideline for traditional web development is less than 10 seconds before the user gets bored and leaves the site, so this is easy to exceed with a big Silverlight app.
The only solution to this problem is splitting the app into multiple downloadable pieces. That does not necessarily mean multiple apps as Silverlight supports downloading of additional XAP files (usually modules).
The most recent solutions involve producing separate components, that are downloaded on demand, on the principal that not all functions of a website are used by a single user every time they visit. MEF and Prism are good example of this type of development pattern.
Runtime performance
This one is more difficult as there are several factors that contribute to poor performance.
- Poor reuse of memory (objects living on long after they should have gone into the light, or just too much loaded at once)
- Overuse of animation (this is often the biggest performance hit as it is so easy to change a lot of screen pixels in Silverlight)
- Inefficient code (assume any algorithm can be replaced with something faster, although there is normally a trade-off between speed and memory usage).
All of these need to be addressed, but it comes down to the skill and experience of the developers as to how efficient it could be made to run.
My advice:
- Go with a single-app/many separate module pattern like MEF
or Prism to break your app into
discrete modules.
- Be careful with excessive animations if performance is key.
- Plan general efficiency in from day 1 and you will avoid heartache later.
Hope this helps.