How does Silverlight web browser application performance affected by number of pages or child pages in application?

If you have practical experience deploying Silverlight image viewing and deep zoom applications, does number of application pages affect performance? Let's say download or execution time, display time, etc.

The need is to prvide users with a lot of dedicated interfaces to view and process images including deepzoom images.

What is better:

1. to have one application containing 5 Pages to display different variations of image UI's with 3 child windows per each page (total of 15 pages) or
2. to have 5 different applications with one main page and 3 child pages. but make them work together via webservices or simply by linking the p开发者_如何学编程ages html at run time.

Any thoughts? Thanks, Val

---

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.