Tuesday , 2 September 2014
Home » Silverlight » Performance

Performance

Pros and Cons of application library caching and GPU acceleration in Silverlight

Reduce XAP size by using application library caching

Advantages

This reduces the XAP size by allowing those libraries configured with a dllname .extmap.xml file to be placed in individual zip files. These zip files will be requested as part of the initial XAP download.

The advantage comes in two scenarios. First if you update your code and rebuild the XAP most of the time the only thing that changes is the XAP, zip files remain unchanged. Hence when a client revisits your app and needs to download the latest version it may well be that only the XAP gets fetched, the zips being the same get served out of the browser cache (probably after a "304 Not Modified" response from the server).

The other scenario is where you have multiple SL applications on your site. They will share the same zips and therefore the total download for multiple apps is much reduced.

Disadvantages

For a one off application the first client visit will be a download at least as expensive if not more expensive than had the all the libraries been kept in the XAP. In some uses (high number of unique visitors of a site with a single app) it may be more desirable to keep the single XAP, especially if the XAP itself doesn’t change that often.

Where there are multiple XAPs sharing the same set of library zips there is a danger of "DLL Hell". Potentially someone can update a XAP which uses newer versions of libraries that the other XAPS have not been tested with and inadvertently break all the other XAPS. There are good practices that can eliminate this problem but it takes a little more effort than flicking on the Checkbox.

Conclusion

In light particularly of the second disadvantage I think it was a sensible choice not to default this feature on.

Use GPU Acceleration

I’m not going to go into the advantages/disadvantages of this. Just answer why its off by default.

You don’t get any advantage by just turning it on, you need to enable which elements in the XAML will get to use it via the CacheMode property. In addition depending on what you are doing this may still not bring you any advantages.

Just turning it on will consume extra resources such as video memory, you wouldn’t want that to happen unless you’ve specfically gone ahead used CacheMode at least somewhere in your app and hopefully where it would make a real difference. Also it is possible to get it wrong and make things worse.

How to profile a silverlight application

Try profiling with the Visual Studio profiler in order to get a good measure of your managed code and the native code executing within Silverlight. The profiler will help point you to where you’re spending the most of your time (what the hot path’s are) and whether or not your spending it in framework (SL) code or your own code.

The basics of profiling are:

  1. Open a Visual Studio Command Prompt (as admin), ‘cd’ to the directory where your DLL and PDB files are (typically your "Debug" folder)
  2. VSPerfClrEnv /sampleon
  3. VSPerfCmd -start:sample -output:somefile.vsp VSPerfCmd -globalon VSPerfCmd -launch:"c:\Program Files (x86)\Internet Explorer\iexplore.exe" -args:""
  4. VSPerfCmd -shutdown
  5. VSPerfClrEnv /off

You can find detailed instructions on using the profiler on my blog:http://www.nachmore.com/2010/profiling-silverlight-4-with-visual-studio-2010/

If you find that you are spending time within Silverlight, track down the code path to see where your code is triggering the expensive calls, so that you can then investigate specific solutions based on the cause of the slow down.

Update :

Performance Wizard for Silverlight – taken from VS2010 SP1 KB.

Visual Studio 2010 SP1 enables you to tune the Silverlight application performance by profiling the code. A traditional code profiler cannot tune the rendering performance for Silverlight applications. Many higher-level profilers are added to Visual Studio 2010 SP1 so that you can better determine which parts of the application consume time.

For more details refer to article Profiling Silverlight Applications After Installing Visual Studio 2010 Service Pack ?

Optimize Silverlight applications for smaller size

When putting content on the web, it’s important to get that content to the user as quickly as possible. In general, reducing the amount of data users need to download is a big step in the right direction. As Silverlight applications are usually linked with rich user interface these includes lot of images and other resources.

Performance can become a real issue when the user has to download a total of 5MB or more just to run your application.

In this article I will talk about a few tricks to reduce the size of your silverlight application and thereby reduce the time it takes the application to start on the client.

Remove Extra assembly

By default Visual Studio will add quite a lot assemblies to your Silverlight applications. You application might not require all these assemblies.

The first step in optimizing your silverlight application for size is to remove excess assemblies from the application. A good way to achieve the desirect effect is to remove all assembly references, except for the System reference.

After that you will need to recompile and check for any compile errors that are caused by missing references.A quick way to get rid of these unused usings is to right click on them in Visual Studio 2008/2010 and choose Organize usings / Remove unused usings.

Make sure that you’re including references to assemblies that you actually need and nothing more. Sometimes you’ll need a reference to an assembly but you don’t want it set to "Copy Local", as that adds to the XAP. Visual Studio 2010 is usually good about automatically setting "Copy Local" when appropriate. For example, System.Windows.Controls is not part of the runtime (it’s a part of the SDK). Visual Studio knows this and when you add System.Windows.Controls to the project it automatically sets "Copy Local" to true. But when in doubt about an assembly reference, try setting "Copy Local" to false and see what happens. If your application builds and runs fine, then you’re good.

Reducing Size of final XAP package

The silverlight XAP package format is actually a ZIP container with a special manifest inside that is recognized by the silverlight runtime. The package that Visual Studio will create however is not compressed as efficient as it could be. However Visual Studio 201o has improved quite a bit in this area.

Another tip to get more bang for the megabyte is to unpack the XAP package and repack it using Winzip, Winrar or any other zip application.

Reduce XAP size by using application library caching

(not available for out-of-browser applications). Check this option in Visual Studio 2010 and when your project is built there will be extra files automatically generated. So you’ll have to upload your XAP file and any auto-generated ZIP files to the same directory. The generated ZIP files contain any external assemblies that your XAP require. Behind the scenes this relationship is automatically maintained with the AppManifest. This feature is pretty cool and very easy to use. You should note, however, that the whole idea behind it is caching. And so it speeds up requests from repeat visitors, but in practice it doesn’t do a thing to speed up the experience for a new visitor. Read more about this featurefrom Microsoft.

Other Tools to Automate everything related to optimization of Silverlight application for You

  1. XAPs Minifier Visual Studio 2010 plug-in

sometimes when working with a Silverlight app you might have an assembly reference that has been set to "Copy Local" when it doesn’t need to be. This is easy to overlook when working with a large Silverlight app composed of multiple projects. The XAPs Minifier is intended to remove any redundant or unnecessary assemblies.

2. ComponentOne XAPOptimizer

The XAPOptimizer is not free, but it does take optimization to another level. It goes beyond assembly removal. It’ll dig into every assembly through reflection and actually detect unnecessary classes, resources and entire sections of XAML. It’s also configurable in case it makes a mistake you can actually specify what to remove and save your settings. On top of this, it’ll optionally obfuscate your application, making it hard to reverse-engineer.

Conclusion

Often the most significant optimizations involve removing unnecessary or unused components or assemblies.