I have a complex control that is taking a very long to Initialize. Whilst I am able to use the WPF performance kit to profile the controls Layout time, I haven't found a way to analyze initialization time.
Im wondering if there is any way I can analyze where the hot spot is in initializing the controls hierarchy, styles, resources etc.
I don't know any tool which will allow debugging or profiling the Initialization process.
you can use snoop to see the visual tree.
you can use pistachio to profile unused resources.
eventually you'll have to remove all UI elements from the control and start adding them one by one while counting the initialization time that way you'll be able to figure out the hot spot.
of course you have to take in account the binding in the specific use case which result in the performance hit
Related
Short Version:
Is dynamically attaching/detaching WPF behaviors to/from a control at runtime a feasible practice in WPF or should I be looking for something different to solve my problem?
Long version:
I have a WPF control which represents a drawing surface. The user can use any one of a number of mouse "tools". One tool draws a line, one draws a polyline, one merely selects exiting items, etc. etc.
I handle this in code-behind for mouse events. Unfortunately no matter how much I try to generalize it, there is a lot of switching on tool type because the tools do very different things. Consequently, it is difficult to maintain. Adding new tools requires too many edits and testing. The handlers keep on growing larger.
I need to make this control relatively easy for the next developer on this project to understand it and to add a new tool without worrying about breaking anything.
It would seem that WPF behaviors would provide a natural way to simplify this and make it more modular; You set a particular "tool behavior" on the control and it handles the only mouse events it needs, altering the control properties as necessary. Different tool code is no longer mixed together.
But this approach differs from the way I've used WPF behaviors in the past. It would require me be able to dynamically attach/detach behaviors at run time with the push of a button. That is new to me. Usually I just have a simple behavior that I declare on a control once in XAML and it stays that way for the lifetime of the control. In fact, all of the WPF Behavior examples I've ever seen have been the sort where you set up the behavior one time in XAML and forget about it.
So I'm wondering has anyone out there done something like this? Is this an approach I should pursue or would it probably end up proving unwieldy? Or should I be looking for a different solution?
I am just wondering if anybody knows anything about the speed of the WinsForms panel control relative to the number of controls placed in it.
I have panels that I need to populate with hundreds of controls and it seems to slow down exponentially. I have tried making the panel invisible when populating it and this doesn't seem to help.
I am asking for two reasons:
To determine if this slow down is the result of the panel control or
a quite complicated (for me) bit of code that is handling the panel
and adding the items to it.
If it is the result of the panel, then I would like to determine if there
is anything I can do about it. I am quite a ways into the project
and the project depends upon panels that contain these controls.
Thanks for your time.
My level of expertise is fairly amateur BTW.
You have not shown your code to load the panel. Moreover you need to add more information in your problem about the controls and loading process. With general assumptions, to speed up you can do :-
Lazy load. User will not interact with hundreds of control at a given time. So, load the controls on demand.
Populate the controls in background thread, and make them ready just before they are required to be shown.
Load them based on the priority of the user interaction.
In my program, there is a map editor, after loading the information from the database, I need to generate some custom controls (6000-10000 depending on the map). Unfortunately it locks the user's screen for 10-20 seconds.
How can I do using lazy loading? How can I do without crash and lock screen?
This question is much to broad. But i can give you a number of hints.
First of all i'am pretty sure you don't need so many custom controls. Think about how many input devices the user has, he can't interact with that many controls at the same time. So you can "cheat" about these controls in a couple of different ways. For example, display an image of the control, and switch it if the user starts to interact with it.
Another thing is, you don't need what you don't see. Why create a list of 10000 Elements if only 10 will fit on the screen? There is no reason, thats why there are ways to mitigate that, one is called Virtualization which can be done in a number of ways. You can use UI Virtualization, by defer the loading of the ui components or use data virtualization.
Another thing, in cooperation with data virtualization is to use threads or a background worker to handle the load of that much data. Create your data in batches to give the UI Thread time to handle the windows messages.
Look into Binding or doing the work in a Background thread?
If they are in a ListView, look into VirtualMode:
http://msdn.microsoft.com/en-us/library/system.windows.forms.listview.virtualmode.aspx
What are you loading these controls into? Are you doing it in the UI thread?
Use TPL (Task Parallel Library) to do the DB tasks on a separate thread... it looks like this:
Task.Factory.StartNew(() => MyLongRunningMethod));
Check out this great article over on CodeProject for more information...
EDIT: As noted below the original answer implied that somehow controls can be generated on a separate thread but in reality as a part of the visual tree and therefore the UI, controls must be generated on the UI thread so that was not a valid suggestion...
EDIT: Don't see how it would be possible to fit 10000 custom controls on a signle screen so there must be a way to use some type of virtualization schema where only visible controls would get generated and the rest of the controls would get generated on demand...
I have a WPF application that renders input forms based on form-configurations saved in a database.
The forms have many controls (100+) and most of these controls are derived from a TextBox-control. On some machines (fast Hardware, Win7 32Bit, also some elder, Windows XP 32Bit), after entering data to a lot of these forms, input performance goes down. Every keystroke gets a delay of some milliseconds and the only solution to resolve this is to close the application and restart it.
My derived control overrides the metadata of the DefaultStyleKeyProperty to set a custom template.
I'm currently reasearching the app in SciTech memory profiler, but maybe someone has already experienced a similar problem with derived TextBoxes and can give me a hint and spare me some more hours/days investigating the problem?
Update
Look also here
It sounds like you may have something stopping the controls on the "used forms" being GCed.
Firstly opening and use as many forms as possible looking at the windows task manager to see if you memory usage is going up – if it is not there is no point looking for memory leeks
Check you are removing all events handlers you forms/controls have put on any long lived objects.
Check that any objects you databind to implement INotifyPropertyChanged, see KB938416
I have in the past had good results using the Red Gate memory profiler.
You don’t need to have controls created that the user can’t see, 100+ controls will have a cost.
Can you use something list a list control in virtual mode, so your TextBox controls are only created when visible.
I find that the winform tool tips behave very erratically. They seem to randomly decide to do nothing, show up or disappear when I perform the same hovering/clicking/etc actions.
Is there some pattern that I'm missing? Do I just not understand the UI technique to bring up a tooltip? Is this a common problem? Do people actually expect tool tips to work this way?
Tooltips display automatically. That's a bit of a problem, the native Windows control has counter-measures in place to avoid displaying tips too often, potentially wearing out the user with info that has been shown frequently enough. Not exactly sure how that rate limiting is implemented, accumulated time is a factor (like 60 seconds), possibly also the number of times it was displayed.
The SDK docs do not document the implementation details. There is also no message available to forcibly reset the rate limiter. I do think that passing another control in the Show() method resets it.
All and all, it does mean that the ToolTip control is really only suitable to act as a traditional tool tip. It doesn't work well as a 'dynamic label'. which is your alternative, a Label control with BackColor = Info. Albeit it not quite the same because you cannot easily make it a top-level window.