I'm doing some performance minded work on an existing winforms project.
This form is made dynamically rather than at design time, and loads a few dozen user controls, as well as binding them to a DataSet object with a small set of data.
Using some profiling tools (ANTS, Avicode), i can see most of time, around 50%, is taken by the code i have to show a tab page i have on the form. drilling down, i see it divides roughly in half to two operations:
1) a long line of VisibleChanged/SetVisibility/SetVisibleCore operations, all in the winforms namespaces. How can i know if the time it takes (4.5 seconds in my case) is sane? I do have a lot of user controls in my form.
2) A long line of RightToLeftChanged operations, again, around 4.5 seconds. Here too, I'm wondering if this is expected/sane performance of WinForms.
any advice regarding finding the performance issues here or whether the performance i'm getting is normal would go a long way to help. Thanks in advance :)
Related
I haven't used Telerik controls before for desktop application. I'm wondering why my application is slow. My system spec is very good. For example if I select one control to add property and then I go for next control it takes some seconds to get selected. Even when I save, it takes some seconds to save. I have to wait every time I do something and save. My computer is in network. And I guess my computer is in different location not where I work. Is that the reason for slow performance even though the system spec is good enough?
Thank You!
I started converting a WinForms application of mine over to WPF, and there was one major issue I noticed right off the bat: even on a completely blank WPF project, the application will take roughly a second to open, whereas even heavy/intense WinForms applications I've written start up instantly or with no noticeable delay. Is this a global issue, or is it just me? If the former, is there any way to circumvent this? I find it incredibly annoying.
I apologise if this is a duplicate question (since it seems like something really basic), but I can't find any information on this.
I have a complex WPF application that is using a lot of resources from the shared Resource Dictionary.
The first Window initialized takes 8 seconds to initialize. The performance issue is less on SSD disk drives but still it requires 2 seconds.
I tried to use the Visual Studio Profiler and it shows big expense of time on InitializeComponent();
of the windows that needs to be displayed.
I believe it is related to the Resource dictionary used but I can't replace it because I really need it and because all windows and WPF elements are using the StaticResource references.
I tried to optimize the launch as much as it is possible.
I created many background threads but this didn't helped too much. Whenever a window needs to be displayed it must be attached on UI thread under the same Dispatcher. This makes a big performance issue and all UI and any Progress bar left on the screen is blocked.
So to summarize. From the point when the ShowDialog is called until the window is displayed it
takes 8 seconds. This is visible only on the first window. Any other window opened after that is displayed quickly.
Now I am asking firstly what happens in the background and why this delay is so big and second what can be done to increase the startup speed.
I didn't mentioned but there are no Exceptions or DataErrors present during the launch so it is
not related to Exceptions.
I believe it is something with the initialization of Buttons and other components because almost all of them have the ControlTemplate restyled.
Lots of assemblies need to be loaded and lots of code must be JIT compiled before your first window can be shown. One useful technique to reduce startup time is to structure your code in such a way that types are not loaded before they are needed. It may be preferable to get a blank window up on screen with a wait indicator before delving into code outside of the core WPF assemblies. Optimize for that scenario.
Avoid loading images/media and other resources too early if you are trying to get something up on the screen as soon as possible.
Avoid loading any data synchronously, and do as little in your view and view model constructors as possible. Defer the loading of data until your view has been shown (throw up a wait indicator if necessary).
If you think your Xaml resources are a problem, split them up, and have each view pull in only the resources it needs. Don't merge them into App.xaml. You might also look into how to share the resources more efficiently across multiple views.
Throwing up a splash screen can improve the perceived startup time. Getting anything up on the screen to let the user know your app is actually doing something goes a long way.
Lastly, don't fret too much; poor startup time is the hallmark of WPF applications, and in the end, there's only so much you can do.
You can also use the ProfileOptimization class to improve startup time over subsequent sessions of the program. May not help you, the developer, but may have an impact on your users for the better.
The main form of my application constantly turns white in the designer when I perform the following steps:
1) Open form in design mode (All controls are visible at this point)
2) View source code for form
3) Switch back to design view
After performing the steps above, there is nothing visible in design mode for the form (not even the form). I only have this issue with one form in my application and, unfortunately it is my main form where there is a lot of logic. The workaround is to always close the form and reopen it in design mode show that all the components are visible again. I have experienced erratic errors with the designer when I am low on available memory but, this form always produces this symptom and is the only one. Any ideas as to what is causing this? I guess I could always create a new form and try moving all the controls and logic over but, I'd prefer to avoid the work if there is a simpler option.
The diagnostic is that the Paint event or OnPaint method of a control is misbehaving. These methods run at design time so you'll get an accurate visual representation of the control, the way for example that you can see the Image property of a PictureBox at design time. When such a paint event gets stuck in a loop then the entire form stops rendering properly. Beyond a simple bug, the typical reason is that the code is getting confuzzled by the non-standard runtime environment in design mode. You use the DesignMode property to ensure that such code won't cause trouble and is disabled in design mode.
Finding the misbehaving code is the challenge, especially when these are not controls you wrote yourself. Short from removing controls one by one to find the troublemaker, you can use the debugger by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one.
From personal experience, I can confirm that this is an occasional issue in both Visual Studio 2003 & 2005 whether VB or C# is used. We patched both versions to the latest service pack and even got hotfixes directly from Microsoft, neither of which resolved the issue.
In the case of VB in Visual Studio 2003, the disappearance of the controls also removed the underlying designer code so we kept having to restore the deleted code from our version control system. Very annoying - as we'd often lose code changes and have to start over.
You defiantly should check the next link:
https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4
here's a quote from the page:
Using the StarDefinitionsCanExceedAvailableSpace Override This setting
overrides the new GridRendering behavior and basically lets you run
with a .NET 4.7.x target in your project, but keeps the old behavior
that was used in previous versions.
There is a configuration setting that can be set in app.config for
your application:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
/>
</runtime>
</configuration>
I can verify that using that switch lets me run 4.7.1 and not see the lock up in any scaling mode. After I
had my running version in 4.6.2 back, I once again moved up to 4.7.1
in a separate branch to try this out and sure enough the switch made
the application run targeted with 4.7.1. So there's a hacky
workaround.
It's a workaround though. This 'fix' according to Microsoft improves
grid rendering allocations, providing more precise sizing and also
improves performance and reduces memory usage. On paper this is a
great improvement, but... well, side effects 😃
I suspect this issue is not wildly common as there was not very much
info to be found about it. I think Markdown Monster makes this issue
come up because the startup sequence has a lot of window manipulation.
MM uses the MahApps UI framework which uses Window Animation and extra
rendering frames for the main window, and MM itself moves the window
offscreen for initial render and adjusts window sizing based on screen
sizes and DPI settings if the window doesn't fit on the screen or
would otherwise be offscreen. IOW, there's a bit of gyration to get
the initial window onto the screen that is more likely to hit this bug
than a simple WPF form.
So I doubt that every application needs to worry about this, but if
you have a 4.7.x WPF app it might be a good idea to try it out at
various resolutions and scale levels just to see how it fares.
i have a C# application, and id like to be able to make a system, so that within the program, you can display the sourcecode of the application. easy enough so far right?
well, i need them to be able to edit that code, almost like the debug break option... then load the new code and continue without stopping the program. so my problem is, that when this app loads its several thousand lines of code, and it takes a good block of time. after its loaded, it needs to do several hundred operations before allowing user input the first time it loads. also, it has a tcp client in it, and it is very important that it does not get disconnected.
i want people to be able to edit the source, click a button, and wait a few seconds, and have the new code inserted and "rehashed" so to speak, without having to break the overall function of the application.
im looking thorough code examples where possible and an input weather this is possible or not
~ thanks
If you want to allow people to make arbitrary changes to your program, that would be very complex. However, if you want to let them change specific behavior (like rewriting a calculation algorithm) you could have a look at Microsoft.CSharp.CSharpCodeProvide as discussed here.
I don't think you can do that (change a .net app without rebuilding it) but you can have dynamic code loaded and run at any time..
Some people use plugins with Boo, people can change the plugins and these can be loaded at any time by the main app.
But I would suggest you have a look at the Ruby usage inside SilverLight..
This is something completely different, but its something I'm reading on how to start playing with Dynamic code handling: here