I have a serious Performance issue in my Silverlight project, when I run my project the CPU usage is going up 80% - 90%
the computer go down!!!, these are the major feature of the project:
1- We are using Silverlight 4.
3- We are using MVVM pattern, which means all data source, states are Binding with the properties in the View Model.
4- Most of the controls are created dynamicly in code.
5- We have a reference for the Main control in the Main view model which is the container of all generated control.
6- In our controls we have many of layouts (Grids).
7- We have Main view model which is the container of all children view models in the system.
8- We have lots of states and animations.
9- We don't use the Relay commands, we are using the regular commands and events, so we raise the event and handle it's parent (we have lots of events).
Is there any of the above causes the performance problem??? I thinks that there is a issue in the Silverlight itself, is there any Silvelight 4 update for performance.
I appreciate any help,
Thanks
A complex application is likely to have performance issues to resolve. The use of data-binding and various events, while great for structuring your application, can make it hard to see what's going on. The control flow may not be obvious, for example code may be executing multiple times due to cascading events/property changes.
I'd recommend using a profiler to see what is consuming most CPU time - JetBrains DotTrace is one I've used with Silverlight, see other questions for more. Then you can focus on the problem areas.
If your application is becoming progressively slower over time, it would be worth investigating whether there are memory leaks also.
Are you using DropShadowEffect anywhere? In which case, you might want to try removing them. I've had this issue once. A template included a DropShadowEffect which made the CPU max out, removing it solved the problem.
In my experience, your 9th point is usually the culprit.
Make sure that you release the event handlers in your classes when you're done with them. In almost all cases where I've seen performance degradation in Silveright or WPF is was the improper handling of event delegates.
As one of the comments pointed out, use a performance profiler and you'll most likely see that the event handlers are consuming an inordinate amount of RAM...meaning that they're sticking around after they're supposed to, and responding to events.
So the performance issue stems from having many objects or controls staying in memory and responding to events.
That's my best guess.
Hope it helps.
Related
Do the xaml animations block the main thread? I'm showing a big grid with lots of data and several animations and even with everything (but the property changes) on background threads the UI is far from being smooth.
As I have several Dispatcher.BeginInvoke (and some Invoke when needed) I was thinking that maybe the animations make the invokes to go slower. Am I right?
Thanks in advance.
I'd recommend investing in a profiler. Certainly, animations run on the UI thread and heavy use of animations might be the cause of the choppiness, but there is no way for us to know for sure.
My preference for profiling C# is dotTrace, but there are tons of others out there. There are even WPF-specific diagnostic tools from Microsoft in the WPF Performance Suite, but I haven't tried them.
I'm just getting started in the exciting world of WPF development, having been a C++ developer for many years.
Testing applications with rich user interfaces has of course, always been hard. One of the problems compounding this has traditionally been that in most Windows apps, the UI, the UI logic and the App logic are all completely interdependent, and cannot be tested in isolation.
I'm very drawn to the MVVM approach that will allow me to separate the UI from the application, and run large amounts of automated tests on my view models, underneath which all my logic will be, with the view being a fairly dumb client of the view model.
That's all well and good, and neatly separates out testing of the application logic from the application UI. BUT, it provides no solution for actually testing the UI itself. Even though the view will typically contain very little logic, it will still have the potential to contain a huge amount of bugs of various kinds.
What's the current state of the art in testing the view itself?
Thanks
Tom
This is always a double edged sword. I see it as attempting to grab the low hanging fruit and build from there.
In theory the MVVM purist would state that absolutely no logic exists in the View's code behind. Making use of Prism for instance can help alleviate this as well as other varying frameworks out there. So coming at it from this angle it begins to get to the point of no logic existing in the View...fair enough, are we then going to begin testing the bindings? You could, however depending on the sizing of the app what is the return on that investment?
What I think this boils down to is where do you draw the line? For instance, even if you are testing the View, you will most likely be hooking into the code, you're white box testing at that point. You then can argue the black box angle, that only testing without internal hooks is valid. You can see that it becomes a circular nightmare.
In general I have focused on the big ticket items and went from there, testing what was possible with the time allotted.
Think of it this way...with a UI you can begin this fiasco of testing the coloring on every button, along with the placement, etc... That's silly to me. Automate the bulk of UI testing at the Model, ViewModel, layer and if you so desire test the bindings of your View. Other then that I would suggest the ad-hoc manual effort every UI developer should be doing at their workstation.
WPF and MVVM doesn't change the process of testing an application's UI. It just radically reduces the number of defects you'll find while doing so, because so much of the stuff you'd normally find and fix during UI testing is now found and fixed during view model testing.
I have some performance related questions about SL Enterprise app development.
-We have 10.000 rows binding to an ItemsSource control. (A total of 100.000+ UIElements when databound)
Q1.How to do this binding in another thread? Because Silverlight gets stuck while the binding happens.
Q2.Any other ways to do this that you suggest with the same visual flexibility like we have in an ItemsControl.
-We are pulling a total of 60MB (unzipped binary serialized XML) data from server and letting our SL users use it for a period of 20 minutes.
Q1.We have some memory leaks and getting hard time to figure out what’s staying in the memory? Do we have a tool to show this?
According to our latest test UIElements are the ones filling the memory. We have 5 nested Itemscontrols, tracking a lot of “loaded” events of inner control in order to fill the appropriate values with calculations. As far as I see virtualization is not working on Items control.
Thanks for all your time.
If you are using the DataGrid, Virtualization should be on by default.
Pulling that much data at one time might also pose a problem. I'd try to find some sort of solution that involves server-side paging.
EDIT:
Just saw that you are using an ItemsControl. The biggest performance boost you'll see (before even getting server paging to work) would be to get virtualization working. Here's a good article about doing it with a generalized ItemsControl (It also addresses your problem with events not firing correctly):
http://blogs.claritycon.com/blogs/lee_roth/archive/2009/09/16/custom-panels-in-silverlight-wpf-part-4-virtualization.aspx
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.
I love programming with and for Windows Presentation Framework. Mostly I write browser-like apps using WPF and XAML.
But what really annoys me is the slowness of WPF. A simple page with only a few controls loads fast enough, but as soon as a page is a teeny weeny bit more complex, like containing a lot of data entry fields, one or two tab controls, and stuff, it gets painful.
Loading of such a page can take more than one second. Seconds, indeed, especially on not so fast computers (read: the customers computers) it can take ages.
Same with changing values on the page. Everything about the WPF UI is somehow sluggy.
This is so mean! They give me this beautiful framework, but make it so excruciatingly slow so I'll have to apologize to our customers all the time!
My Question:
How do you speed up WPF?
How do you profile bottlenecks?
How do you deal with the slowness?
Since this seems to be an universal problem with WPF, I'm looking for general advice, useful for many situations and problems.
Some other related questions:
What tools do you use for WPF development
Tools to develop WPF or Silverlight applications
How do you speed up WPF?
Often after using one of the following profiling tools it is obvious what is causing my bottlenecks.
If memory is the issue then I virtualize my data.
If render time is the issue then I virtualize the controls or simplify control templates where possible.
If processing time is the issue I try to improve my algorithm or move that work to a background thread and show a throbber in my ui while the work is going.
How do you profile bottlenecks?
.NET Memory Pofiler
dotTrace
Performance Profiling Tools for WPF
Snoop
Crack.NET
How do you deal with the slowness?
Profiling and counseling.
Install SP1... Loads of very cool performance increases for WPF!!!
Read more here
Here is a example of 2 enhanchements made in SP1: Deffered scrolling & UI Element recyceling!!!
I can not add comments, that's why I post a new answer to this: I've found this video from the pdc09 that gives some ideas about how to profile wpf apps and because it helped me lot, I want to share the link:
Advanced WPF Application Performance Tuning and Analysis
WPF is meant for computers with modern graphics cards. Do your clients have modern graphics cards capable of running Aero? If your clients have older graphics cards, WPF will fall back to software rendering which runs extremely slow in comparison to hardware accelerated graphics.
You also might want to profile your application to make sure that it is actually WPF that is the slow part. It's possible that there is something else that is actually the bottleneck.
avoiding animations also helps a lot sometimes. if you have to use animations, decrease the framerate, this will improve "Feeled" performance
Remove alpha transparency/ bitmap effects.
can you give more details?
I only noticed a slow performance when I use something like a listview or a grid that has some complexity. The solution is to simplify it.
Other than that I only noticed a slow performance when loading the app for the first time.
HTH
I find it helpful to side-step the XAML, and write the entire UI in C#. This lets me precisely control when the controls are created and loaded. It also helps me understand what XAML is doing "under the covers".