I currently use DevExpress controls heavily in an application. The controls are great and speed-up development time dramatically (and hence, I wouldn't want to ditch them) however, I have a few issues with their performance.
My application is a Shell/Modules/Views&ViewModels application (it follows a lot of the design patterns you would find in Prism).
When a view is first loaded it takes an extremely long time to display (on some of my users PCs with slow machines we're talking 5+ seconds of just hanging there). The time it takes apparently depends on the usage of DX controls (how many ones are on there that haven't been seen before by the application).
When you destroy the view and re-open it, it opens in less than a second. The ViewModel in my test cases/performance profiles has been made to re-create each time - so there is no shared state within my code between invocations of the view (no singleton injected objects).
After a bit of discussion and research I appear to have narrowed down the problem to on-demand loading of the template files for the DX controls.
There is a thread here about that:
http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q382256
which references:
http://www.devexpress.com/Support/Center/p/B201967.aspx & DevExpress controls for WPF load time
The solution described in these threads is to either display a loading indicator or to use a hidden window with controls on it at start-up. Neither of these options are something I'd like to do (and the hidden window option didn't appear to gain much performance when I tried a simple example, interestingly - which also suggests that I might be missing something).
What I am hoping to do is to pre-load template files that I know I'm going to need on a background thread. Is there any way I can do this in WPF? (I'm thinking this is more a general WPF thing rather than a DevExpress thing - even if it's something that needs to be implemented in the DX libraries themselves).
Any ideas for either me or the guys at DevExpress?
What you can do in the background thread is to preload all the required assemblies. Also make sure they are nged-ed. The UI controls need to be initialized from the UI thread.
Related
So I have multiple controls I want to render scenes to.
I have a Device instance for each control as well as several other objects like shaders I need to compile for each control and so on.
I wonder if this is a good approach to have multiple devices and all the objects for each control?
I get pretty good performance from it though. It's just I want to save memory and setup time. Because for example the shaders are the same for each instance and need to be loaded and compiled each time. I can't have them statically because they are restricted to the same device when I tried. I tried to make the Device static and so I can have the shader objects static too, but I seem to run in a problem where the context gets corrupted, even if only one thread executes them. Maybe it is because I can't rely that the GUI thread will always finish the context (which is statically used by all controls) state and render before going to the next and this corrupts my state.
So my issue and concern is more about the memory it needs and time to load (feels pretty slow and heavy), than the performance of drawing (which is pretty good and satisying). I read there are no "best practices" in general but maybe some of you have some hints what I could improve.
Thanks for any help
Instead of creating a different device for each control, I think it is better to create a different swap chain for each control and all controls/swapchains to share/be created by the same device.
I have made a rather complex .NET 4.0 (C#) Windows Forms application using Visual Studio 2013. The question is quite general though, and should be applicable for other versions of .NET and VS as well.
On startup the system reads config file, parses file folders and reads file content, reads data from database, performs a web request and adds data to a lot of controls on the main startup form.
I want to avoid having a splash screen with "waiting-hourglass", the goal is to make the application startup fast and show the main form immediately.
My solution has been to use backgroundworker for some of the startup tasks, making the application visible and responsive while data are fetched. The user can then choose to navigate away from the startup form and start doing other tasks without having to wait for all the startup procedures to be completed.
Is use of backgroundworker suitable for this?
What other methods should be considered instead of, or in addition to, backgroundworker to enable fast startup for an application with a lot of startup procedures?
In my applications I use a splash screen. However, I do not show a waiting-hourglass. Instead it shows a status line where current action is written, e.g. "Read config file", "Connect to database", "Perform web request", etc.
Of course, the application does not start faster but the user does not have the feeling of a hanging program and it appears faster.
In any case it depends if early access availablity makes sense for the user. A good way would also be to just preload the first page / form / tab before the user can see the interface (Splashscreen or loading bar before that).
When the first bits are loaded you could asynchroniously cache more data and only allow the user switching pages / tabs when the caching of these components is completed (you will have to display a "still loading" message or grey out other tabs while doing this to not confuse the user).
You can also just load addditional data if the user chooses to use the page / tab / feature to reduce loading unneccesary information but this will lead to waiting while using the application - it`s up to you.
Technically, as BackgroundWorker is explicitly labeled as obsolete in .NET 4.5 you should see if the introduced await/async would be a more elegant solution for you (See MSDN Asynchronous Programming with Async and Await Introduction)
MSDN says:
The async-based approach to asynchronous programming is preferable to
existing approaches in almost every case. In particular, this approach
is better than BackgroundWorker for IO-bound operations because the
code is simpler and you don't have to guard against race conditions.
See a comparison thread Background Worker vs Await/Async
See a well commented example of backgroundworker code to load GUI data if you choose to use that technique
Rather an advice than an answer:
Is use of backgroundworker suitable for this? - yes.
What other methods should be considered instead of, or in addition to, backgroundworker to enable fast startup for an application with a lot of startup procedures? - consider on-demand a.k.a. lazy loading of data. That is, load the data only when they are actually needed rather than query everything at once possibly many of them without ever being used or looked at. If this is not possible as of your UI setup, consider refining your UI and rethink whether everything should be displayed as is. For example, use separate windows or expanders to display details and query the data when they are made visible. This does not only save you time on app startup but also makes sure that you display any data in an up-to-date manner.
I have Windows Form that I use for a trading application, which, of necessity, has to display a large amount of information updating very rapidly (4 times per second).
The Windows Form I'm using has lots of controls (over 150 buttons and textboxes), and 6 datagridviews with multiple rows to display the information.
I have using different threads to perform the time-consuming operations (HTTPRequests, and various mathematical operations), but I am still finding that the GUI feels sluggish. I've noticed, in particular, that when I add more controls to the Form, things slow down, even though these extra controls are really 'doing' anything.
Can anyone explain why the mere presence of extra controls should make the GUI less responsive and/or recommend a completely different approach? Maybe I shouldn't be using Windows Forms?
Thanks.
It is hard to say something concrete without knowing your code.
A few generic ideas:
From your description, it sounds to me, like your application is very busy with repainting all the controls. Try experimenting with SuspendLayout() and ResumeLayout() and Invalidate() only those Controls that really need repainting.
Check if DoubleBuffering is enabled on both the Form(s) and ChildControls, it should be activated for most controls by default. But make sure you have it on.
Depending on your used .NET Frameworkversion check if you can use async/ await features for keeping the responiveness up.
See article MSDN Magazine article "Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads". This one is a few days old, but still absolutely valid.
Some events are fired more often than you expect or need. Check those events that cause repainting of controls (i.e. this will be where you add values to be displayed to the user) if these fire too often.
Your controls take a lot of memory and I wonder why you have so many, have you considered creating controls on the fly as and when needed. Double Buffering is a must but will not help if you are clogging up memory as it is for graphic display. You need to profile your program using performance counters to find out where the problem lies, are you disposing correctly for instance?
Also are you using too many threads? Are you using the thread pool, if not you should be!
Are your controls loaded with data?
I will think some more but profiling is what you need to do next.
We have a Client-server C# application which freezes when we create 1000 and more kind of objects in UI by using some scripts rather than creating it in UI individually.
We are using lot of event handlers for certain event, but as per my understanding all threads(UI and background) and event handlers are managing properly. Then also our client application freezes. We dont know what the exact reason behind it .
Peak time hanging application took around 16 threads. Task Manager reports it taking more than 90% CPU time.
Can any body tell me the reason behind it
[STAThread]
static void Main()
{
try
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.DoEvents();
Application.Run(new Test());
}
UPDATE
How can i applay lazy loading to Treeview,Listview,and propertygrid.I have used beginupdate,endupdate,double buffering,other than these any methods??
UPDATE
what does high CPU utilization means, my application exe is hanging with 13 threads and some place i heard that if you use ThreadPriority.Lowest it will reduce CPU utilization, will it work still i dont know where to use it properly??
It sounds like you need some sort of lazy loading technique to load the controls on demand as the user scrolls down the form. Loading that many controls at once will inevitably lock the application up.
This article offers some good tips on how to improve the performance of winform apps:
Practical Tips For Boosting The Performance Of Windows Form Apps
Treeviews and Listviews are not very efficient on their own and without adding lots of logic. If you don't have time to optemise them, you may want to check out 3rd party solutions like the AMAZING open source ObjectListView.
It comes in a few flavours to handle specific situations like FastObjectListView which handles millions of records or the TreeListView to handle heirarchy!
It does take a bit of effort to master but nowhere near what it takes to make Treeviews and Listviews into.. well ObjectListViews :D
http://objectlistview.sourceforge.net
http://objectlistview.sourceforge.net/cs/recipes.html#what-flavour-of-objectlistview-do-i-want-to-use
http://objectlistview.sourceforge.net/cs/recipes.html
http://objectlistview.sourceforge.net/cs/gettingStarted.html
I've used it in a few projects myself with great success!!
Cheers,
In my WPF project, if I open a window, the cpu usage is about 30%-50%, but when I minimize this window, the cpu usage drops to 1%. Does somebody know the reason why? Thanks
do you have a lot of bindings (two way) on your screen? This can cause high cpu.
Or a lot of animations?
Ultimately you could use the WPF performance suite to monitor what is causing this high CPU load: http://msdn.microsoft.com/en-us/library/aa969767.aspx
Good post by Rody, I am just going to add a few things, using an answer instead of a comment because comments have max limit..
I would recommend also to use Ants Profiler, it has 2 week trial period - more than enough to figure out what's going on. Also if you post some of your code, people here can quickly point out a few things.
Like for example, if you have, as Rudy pointed out, ton's of Bindings and Animations, as well as, overly complex controls and control templates. Question the unnecessary compositions of Stack panel within a stack panel, within a border...use TextBlocks instead of Labels, or whether you need TextBoxes, if they are read only, use TextBlocks + Border. Are your ItemControl's items too complex? etc...
Also, Ants Profiler can show you your "zombie" objects. Are you disposing correctly, are you recycling your objects, or creating new complex structures every time (for example, when selecting a new date range for your data to display) then rebind to them. If you have data grid cells, does every single one need an expensive something...a popup and extra border.. If you create a border around every cell for some visual effect, re-factor to only have one, and re-position it on the grid.
And the list can go on.
Long story short - WPF is a hog: so you might have to trim things down, or/and be more inventive to keep things pretty with less overhead.
P.S. don't forget to post some code...