I am using the performance analysis tools within Visual Studio to evaluate a rather large and complex WPF application I am working on. I've been able to get cold start time reduced significantly by lazy loading most of the user controls that previously I just loaded on the application start however I am still seeing the bulk of my CPU cycles spent within the assembly 'PresentationFramework.ni.dll'. This doesn't help me figure out what the root cause is because all it says is that the time is spent on a particular user control's 'InitializeComponent' (i.e. XAML parsing) or Window.Show (i.e. XAML parsing).
My question is this: how can I get more granular insights into what specific XAML elements are causing the performance issue?
I am using Visual Studio 2013 and running Windows 8.1. I used to use the old Windows 7 SDK WPF Performance Toolkit that showed a really useful rendering time display that change the color on screen when a particular UIElement was re-drawing but I can't seem to find the same tool that runs on Windows 8.
I suspect the user control has a "deep" visual tree,so it spends time initialising. I did face this myself and used a workaround to load the user controls in background as soon as the application starts.hope this helps.
Related
Using the Application Timeline performance profiler tool in Visual Studio 2017, how do I know which WPF controls are causing the UI thread to spend almost 100% of the time on layouting?
If I drill down in the timeline details I can see a TextBlock node but I can not figure out which control it refers to.
Download the free WPF Performance Suite from here.
The tool contains 2 components by default when installing:
Perforator: Displays the real-time GPU usage and the Frame rates, etc. Also has options to overlay the visually intensive elements!
Visual Profiler: Shows the Visual Tree and the percentage time spent for each element inclusively and exclusively apart from the overall percentage of dispatcher and other lower level layers involved in the rendering and layout.
I'm trying to use MS UI Automation to test a WPF application, and am using the Inspect Object tool (inspect.exe) included with the Windows SDK to look up the AutomationId property on certain elements.
Inspect is behaving very strangely for me:
If I close all applications and start the WPF application and Inspect, inspect is able to see the AutomationId property for various UI elements. Elements which do not have an AutomationId simply show two quotation marks denoting an empty string ("").
After I perform a few actions in the WPF application, inspect.exe hangs and I have to kill it and restart it. Even though the machine's CPU and RAM utilization are around 50% or less, I've tried waiting several minutes--possibly close to 20 or 30 mins on a couple occasions--to no avail.
After restarting, inspect.exe can no longer find an AutomationId for any UI element, even those which did have them previously. What's more, the property is completely missing when hovering the mouse over the WPF application--it is no longer listed at all, not even with an empty string value.
If I move the mouse to another screen (specifically, to another computer, using Mouse Without Borders), the AutomationId property reappears with a value of "FormDot"
If I restart only inspect additional times while the WPF application is still running, inspect still behaves the same as after the first restart.
If I restart only the WPF app while inspect is still running, inspect still behaves the same as after its first restart.
If I close both inspect and the WPF app, then start inspect, then start the WPF app, everything works correctly for a while and inspect finds the AutomationId on a few elements in the WPF app...up until the point at which inspect hangs again.
I've tried running inspect both normally and as an administrator as suggested in https://stackoverflow.com/a/7833728/44737, and it behaves the same either way.
What, if anything, am I doing wrong? Am I just too impatient and do I need to wait a really long time instead of assuming inspect is hung? And why does inspect's behavior regarding AutomationId vary?
There are more than one version of Inspect.exe. The latest to my knowledge is the one dated from 2012 that says version 7.2.0.0 in the help/about dialog box.
The old one doesn't have a tree view on the left with all detected automation elements displayed in a tree, so it's easy to check you're using the right one.
The latest one works quite correctly, however, IMHO, the best tool so far to work with UI Automation is Visual UI Automation Verify. It's a .NET program, and he source is available here:
UI Automation Verify (UIA Verify) Test Automation Framework.
Note that although it's a .NET program, it doesn't use the standard .NET automation dlls (more on that here: What's the difference of UISpy.exe and Inspect.exe? (From Microsoft Windows SDK)).
About the AutomationId property, to clarify my initial comment to the question, I meant its usefulness depends on the program that you're trying to automate.
If you own it as a developer, it's clearly interesting. For example, if you're working with WPF, you can use the x:Uid property, it's clearly meant for UI automation. In the Winforms space, it's also quite useful because UI Automation will use the control's AccessibleName by default and revert to the Name as a fallback, for the AutomationId value.
But there are many apps that don't rely on .NET (browsers, native apps, etc.) Usually, for these apps, it's easier to use other properties.
I have been using inspect.exe for a while on a Microsoft Surface Studio PC (running Windows 10), and my experience is that inspect.exe will hang much more frequently (sometimes always) when Windows Updates are pending. When the updates are out of the way, inspect.exe is still somewhat slow, but much more stable.
I'm using VS2010 WPF / XMAL to create a very detailed order form. It has about 50 data items on it all data-bound in xaml. All is fine in development on my win7 PC. When I deploy the app, via one click or an MSI, the application take seconds to download but up to 5 mins to prepare before the login screen is shown on a windows 7 pc. But on my XP machine it's done in seconds, for exactly the same app!. I've trouble shot the order form by commenting out some of the xaml I found that there is breaking point to the amount of items it can show before I get a start up problem. For example I have 30 items without issue but once you add one more then they very slow startup times occur. It doesn't matter which area of the xaml I comment out as soon as it goes to one extra I get the slow start up time?
I'm only using grids, stack panels and textboxes with single items of data. No lists
Very strange as XP doesn't have this problem. Any ideas?
What graphics cards do you have in each machine? It may be to do with there DirectX compatibility? Changing to software rendering might give you an insight (or at least some consistency.
Try the advice from this page:
http://blogs.msdn.com/b/jgoldb/archive/2010/06/22/software-rendering-usage-in-wpf.aspx
This is the profiling tool you should use for WPF:
http://msdn.microsoft.com/en-us/library/aa969767(v=vs.110).aspx
On my windows 7 pc I changed these setting in symantec antivirus; In Auto-protect I disable the Enable File System Auto-Protect option. Also in the global settings I disabled "Insight for" and " Enable bloodhound heuristic virus detection.
After this my app loaded in a second. When I enabled the virus settings back to what it was and did a reboot my app continued load up in seconds.
I'm not sure why Symantec was inconsistent with this issue... By just adding one extra line of xaml, be it a textbox or a label I get a massive difference in behaviour. My assemblies are sign on my build server with domain certificate so I would assume they are trusted.
I am working on an application that started out as a WinForm but it is now utilizing WPF windows with UI. The interaction is all working beautifully but when the WPF windows are first shown it takes quite a long time (around 1-3 seconds) for them to show. So long that some wonder if the app has crashed (until the content shows). The second time the same windows are invoked they come up quickly. I need them to come up quickly the first time around.
I am making use of styles and control templates that are located as XAML in the resource folder. In the XAML for the WPF windows I then merge them into the windows resource dictionary. The Build Action for those (in VS 2010) needs to be set to "Resource".
Preferably I want to keep them in separate files for easy maintenance.
As far as I understand if the build action was "Page" the XAML would be precompiled and should load faster but if I set it to Page I cannot merge them into the resource dictionary. Is there a way around that?
I am fairly new to this part of WPF and so far my internet search hasn't been successful.
To be clear: I am not talking about WPF controls being embedded in WinForms. I am talking about entirely separate WPF windows that are spawned from the WinForm context.
Is there a way to precompile the entire app or at least all XAML (it's all static, no dynamic XAML)?
Thanks in advance!
Edit: The UIs are not heavy by any means. The ones in question have between 5 and 20 buttons and the usual containers (basically a grid with 1 or 2 stack panels).
Update:
I tried precompilation with "NGEN install appname" - no effect on WPF window load.
I included all resources and templates into the window.xaml - no effect.
(window.xaml is pre-compiled)
I found this really interesting article about pre-jitting upon app load here:
http://www.codeproject.com/KB/dotnet/pre_JIT.aspx
(I used the improvement suggested by 'ittay ophir')
again: no effect on WPF window load...
The load times simply won't change on first load but they are significantly reduced on all consecutive loads (loads in 20ms or less).
What the heck is going on here?
How about loading the XAML asynchronously using XamlReader.LoadAsync Method ?
I have installed the latest Windows 7 SDK which contains the WPF Performance Profiler.
Perforator does display some data when I launch my app, but the Visual Profiler does not display anything. The timeline moves but not data is collected ...
Try this Link
In the WPFPerf Performance Profiling Tools for WPF 4 is now available! post, I mentioned that a bug caused the Visual Profiler to not display any data in certain time zones.
A patch is now available to fix this issue...
First check to see if its working even with a small blank WPF application. If it is not working with a blank WPF app, then it likely is the patch already mentioned (TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available).
However, in my case that wasn't the issue. Visual Profiler has a bug that causes it not to display the Element tree if it doesn't like some of the characters in its main window title bar.
Through hours of trial and error, I was able to trace the root cause of why it would not work on our application even though it would on a blank WPF application. The reason is that our application has a special character in the title bar text (trademark). If we eliminate the special character from the main window title, the element tree shows fine when the visual profiler is attached. I was able to reproduce this issue in the simple blank WPF application too simply by putting the following property on the main window:
<Window ..... Title="Test Application™" >
Looks like a bug in Visual Profiler that somehow is triggered by special characters. I didn't test for other special characters, but likely it isn't just this one.
So the workaround is to remove the special character while you are profiling until they fix this.
Check out if you are using the version 4.0 of WpfPerf. The original that comes with the SDK do not support .net 4