While working on a recent assignment related to establishing and optimizing duplex communication with Silverlight and WCF,we learnt quite a lot of new concepts like HttpPollingDuplex binding with multiple messages mode Http Long Polling designs etc.
While most of these concepts were new we did get a bulb flash on how to improve basic WPF/Silverlight WCF communication!!
All WPF/ Silverlight applications share the same threading model . They have a UI thread and a rendering thread. The rendering thread takes care of the background processing while the UI thread takes care of painting the screen, resizing and the overall look and feel. Whatever happens on the UI thread is primarily synchronous and blocks the UI.
Now whenever we need to work with WCF services without blocking the UI we go for asynchronous calls(In Silverlight we have no option anyway), but the mistake we make is we call the WCF service directly from the UI thread(on say a button click). Now since the webmethod was called from the UI thread its Async Event Handler is also executed on the same thread. So this event handler becomes one of the many tasks the UI thread has to be performed and the end result is a slower UI update. An advantage here is that since we are on the UI thread we can update the UI element directly(else we would have to use a dispatcher!)
How else should we do this?:- An ideal way here would be to separate the task of the UI thread and disturb it only when needed i.e when we need to update the UI.
So basically use worker threads to invoke the webservices and handle their responses and use dispatchers to update the User Interface! So the downside is slightly more complex code to finally update the UI but then you used WPF/Silverlight to get a great and responsive UI..it does come at a cost:-)
Hope this Bulb Flash helps you improve your app performance!!
Until some more flashes!