I have been playing a bit with Silverlight and try to port my Silverlight 3.0 application to Silverlight 4.0.
My application loads different XAP files and upon a user request create an instance of a Xaml user control and adds it to the main container, in a sort of MEF approach in order I can have an extensible and pluggable application.
The application is pretty huge and to keep acceptable the performances and the initial loading I have built up some helper classes to load in the background all pages and user controls that might be used later on.
On Silverlight 3.0 everything was running smoothly without any problem so far.
Switching to SL 4.0 I have noticed that when the process approaches to create the instances of the user controls the layout freezes unexpectedly for a minute and sometimes for more. Looking at the task manager the memory usage of IE jumps from 50MB to 400MB and sometimes up to 1.5 GB.
If the process won't take that much the layout is rendered properly even though the memory usage is still extremely high. Otherwise everything crashes due to out of memory exception.
Running the same application compiled in SL3, the memory used is about 200MB when all the usercontrols are loaded. Time spent to load the application in SL3 is about 10 seconds, while it takes up to 3 mins in SL4 There are no transparencies, no opacities set, no effects and animations in the layout.
User controls are instantied on the fly and added or removed in the visual tree on purpose when the user switches from one screen to another. The resources are all cleaned properly when a usercontrol is removed from the visual tree to allow the GC to operate in the background.
I may do something wrong but I could not figure out where exactly nail out the source of this problem. As far as I know there is no memory profiler in SL4 that can help me out to find where to look at. But again I could not be updated on new debugging tools available.
UPDATE:
Silverlight 4 Service Release to fix Memory Leaks: http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx
Silverlight 4 has known memory leaks and the fix is currently being tested.
Here is a Microsoft Thread about it:
The user "heuertk" is a Microsoft Silverlight Developer....he explains the issues and the status of the fix...
http://forums.silverlight.net/forums/t/171739.aspx
To be honest despite your assertion "The resources are all cleaned properly when a usercontrol is removed from the visual tree" this where I'd start looking. It really does smell of elements of UserControls not being released properly.
This typically occurs when there are long lived (for example static) objects that raise events that more transient objects attach to. If these event handlers aren't detached it leaves these objects hanging around in memory.
I am keep testing and would like to share what I discovered so far.
It might be helpful to understand the behaviors of SL4.
Since it sounded pretty weird the UIThread can take so long to render a bunch of graphic components and considering Microsoft has improved the render pipeline, I have reverted my solution to SL3 but I have kept SL4 installed on my localhost.
The application uses RIA Services and moving back and forth to SL4 means that I have to do some changes in the code as per released documentation.
The application runs extremely smooth more than it was if it is tested with Visual Studio 2008. The memory usage is lower than it was before when SL4 wasn't installed.
As soon as I switch to VS2010 it is a completely different scenario. Memory grows undefinitely, the layout is slow to catch the user interaction and sometimes it freezes as before explained.
I have disabled RIA Services, by using standard Rest service and the process hasn't changed in quality.
In conclusion, considering I will keep testing in order I can finally understand what is really preventing to get the application running in an acceptable mode, I believe the memory issue is due to the debug process of VS 2010 or a combination of VS 2010 and SL4
Just for your info: there is a memory leak when using Silverlight Toolkit Charts in Silverlight 4.0. This is a known bug and Microsoft is working on it.
Silverlight 4 is Leaking everywhere. It Doesn't release memory properly.
Related
We upgraded our development machines and with it, we installed .NET 4.5
Right after that, we noticed our application, which is developed with .NET 4.0 became noticeably slower. This is without touching the source code or what version of .NET the application is compiled against. The problem is, that the application itself is pretty complex and separating possible cause is impossible. The possible causes might include:
General WPF slowness (not probable)
Telerik library (same as above)
WriteableBitmap, which is used heavily even when user doesn't make any actions (yes, SetDirty is used properly)
WCF used to receive "large" amount (~5kB/s) on constant basis through TCP
I'm asking if there is any relevant information about this issue. I was trying to google, but I only get performance tips and no issue that would fit mine. Right now, the workaround is to uninstall 4.5 and install 4.0, which fixes the performance problem.
So, I figured it out.
In the current code, Dispatcher.Invoke is used to synchronize changes from the network queue to the UI. This is called many times per second. To fix this, I used CompositionTarget.Render event with double-buffer to push the network queue to the UI and it fixed the performance problems.
It seems that .NET 4.5 did some changes to the Dispatcher, so it became a bottleneck in our use case.
I've been looking to get some profiling reports on a project I'm working on. I've looked at many of the options out there and I've personally used dotTrace and ANTS before but decided to give the Visual Studio built in Profiling a shot.
So far it seems pretty good all in all. Had to jump through some hoops to get it working in the first instance but its running OK now.
The problem I have is that my project is a Composite WPF application using PRISM which means there are no static references between the EXE file and the majority of the logic which resides in the Module class library projects.
This isn't the first time I've seen some usually very good tools get confused by composite applications so I'm not going to hold that against the profiler. However it does mean that 90% of what I want to profile in the application is actually excluded from the reports and remains completely un-profiled. Not helpful.
I have all the libraries I'm interested in profiling added to the Instrumentation session so it's all ready to go the problem is it doesn't seem to follow the execution paths into my Modules internals.
Has anyone managed to get a PRISM app using a DirectoryLookupModuleEnumerator (no static refs) approach successfully and fully profiled?
HA! The cardboard developer strikes again!
One additional complication in my particular scenario is that my compiled application isn't in the usual bin\Debug locations. Each project copies itself and any dependencies into a completely separate location (kind of like deployment I guess) and then executed from there when I debug.
What I've done to get this working:
The usual nasty post signing shenanigans to get the strong names to play nicely
Instead of going through the wizard simply click Start Performance Analysis under the Analyze menu
This will start the performance analysis and should honour any debug setup in your start up projects properties page.
Go back to the Visual Studio 2012/2013 instance you started from.
Right-click on the Targets node in the Performance Explorer panel.
Select Add Target Binary and then in the file browser select the compiled modules that form the composited parts of your application
Run your app as you wish and then select Stop Profiling when you're done.
Explore to see just how crap your code is! :)
NB: last step is optional.
We have developed an EMR software using WPF in presentation and .NET c# libraries in business layer. WCF service call is used to communicate between server and client. The application using WPF user control for all pages and tabs in the pages. Now the problem is as the user loads pages and tabs the memory consumption increases and its not reduces until the application is stopped. Even if the user closes the old pages the memory consumption never decreases. The system goes on slowing down as the user loads more pages and close them. Some time the user closes the application and takes it again. Even that time the application slows down considering to the first time load performance. How can i solve this situation. It has became a bottle neck for the application now. Can anyone help.
You have to use a memory profiler to find out which parts of your code are holding on to the data. Search for '.NET memory profiler'.
I used EQATEC profiler to profile my custom controls in Silverlight, WPF and Windows Phone. It was really useful.
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
Silverlight Out of Browser technology and WPF ClickOnce on the surface have similarities. Easy and simple deployment, the ability to specify the level of trust access to the underlying host, etc.
What are the key issues I need to consider when choosing one over the other?
To put a finer point on it, I'll be deploying LOB apps on a corporate network running only windows computers.
The big one is cross platform compatibility. If you need you app to run on a mac as well as windows (not sure if Silverlight is supported in Linux yet) then use Silverligt. If you want to make an assumption that all your users will be in a windows machine then go WPF.
Obviously WPF has a much richer toolkit than silverlight so it may well be that silverlight just isn't an option. If I was just building for windows though I know my job would be easier in WPF.
Given that you are targetting a private infrastructure running Windows, two points worth thinking about
Wpf has a richer control tree, whereas Silverlight is a reduced set for compact size
Wpf requires .Net framework installed locally, whereas Silverlight has its own platform independent browser-based runtime
While your target platform will likely have the latest .Net framework installed, rendering this last point moot, keep in mind any updates to the framework [ie .Net4.0 and any future updates] may require a restart of the machine - which is a major pain point for businesses that demand constant-on stateful desktops [ie anything in finance, like banks and trading].
As with all problems, your requirements, not the technology, should inform your solution. :)
You mentioned trust access to the host which I think rules out Silverlight unless you want to run SL4 (beta).
We recently went through a lot of discussion about file system access. Silverlight 3 runs in a partial trust sandbox more or less. You can't maintain a pointer to files in the files system outside of your application's isolated storage. This was an issue for us as we wanted the user to be able to use the application to reference odds and ends on your file system. That said you can allow the users to load and save files from anywhere on the system but you just get/or push the file stream and (to the best of my knowledge) don't have access to the folder or file path information.
Silverlight 4 (in beta) has support for your application running in full trust mode. I haven't played with this yet however and can't speak to how well it works.
In talking with a lot of people who work with both Silverlight and WPF, even those who are excited about Silverlight and push for it strongly, I hear a lot of the say fairly emphatically that if you are going to be developing exclusively for a full-trust Windows environment, WPF is hands-down the obvious choice.
That's not to say that Silverlight is an inferior product or that there aren't times will Silverlight will be the clear winner. But when you say "I'll be deploying LOB apps on a corporate network running only windows computers," it sounds like WPF is the clear winnder.
You could decide to go down the Silverlight route in anticipation of all of the great new OOB feature os SL4. I've even heard rumors that SL and WPF will eventually merge, so it may not even really matter, right? Well, I think what you'll find if you go with Silverlight is that some of the advanced features that you thought were there weren't there in the way you expected. For example, SL4 will be able to run in "Elevated Trust" (not full trust) and you might find this limiting at a frustrating point in the project where a lot of your code base is already in Silverlight.
Certainly keep your eyes on Silverlight, but for your current business case, WPF will likely be the best fit.