WPF C# Application Performance

Question

We have a C# WPF application written in .Net 4.0, which some relatively simple data binding and grid functionality.

The styling invovles a few 'tweaks', including some hover colours and so on.

On 3 machines, out of a deployment covering 20, we are experiencing some very strange performance problems with the UI.

Effectively, after a reboot the application performs well, but after a certain (un-determined) amount of time, the UI becomes incredibly sluggish. For example, hovering the mouse over a button, and there will be a delay of up to a couple of seconds before the hover colour styling gets applied / rendered.

The machines have almost identical specifications. The graphics drivers have been updated, and the starndard setup is two NVidia Quadro 290 cards. Additoinally, we made a 'test' application containing ONLY some test UI components (including the Fluent Ribbon) and no code behind. The problem still occurs.

I have run the Windows Performance Suite to 'deep dive' the runtime WPF, and, very strangely, the UI returns to normal responsiveness if the option 'Disable Dirty Region Support' is ticked. My understanding is that, if anything, this should decrease performance further!!!

I'm at a loss of anything else to try here. A DotTrace performance analysis suggests most of the application time is spent in the PresentationFramework.dll.

[EDIT] All machines are Windows XP SP3.

[EDIT] It is possible that this occurs on all the machines and that the application is not usually allowed to run for long enough to present the problem. We are testing this now.

[EDIT] I should also point out that we are experimenting with the hotfix detailed here. It has been installed on a single machine for the moment, and I will update accordingly.

[EDIT - 24 hours later] So two machines have now been running the same code overnight. On my machine (which has never demonstrated the problem), after initial log in the application was very sluggish, but after less than a minute returned to normal. (I put that down to the machine clearly pulling things off the HDD). On the other machine (which usually demonstrates the problem), the applicaiton improved after a few seconds, but is still now sluggish in comparison to mine.

[EDIT - 48 hours later] On the test machine, the test application is now completely unresponsive (locked) after running for 48 hours. On the same machine, a lightweight 'shell' WPF application (containing a tab control, some buttons and a few panels and grids) is still running and perfectly responsive. So something in these more complex controls is causing this issue... which does indeed point back to (potentially) triggers and delegates that might be the root cause. I'll look to profile the application / controls again. In the mean time does anyone have any advice about how to ensure that the application 'cleans up' after itself at regular intervals? Because we are looking at third party controls here, so my options for editing them are limited!

Would appreciate any tips that can be provided!

Answer 1

try to render wpf in software mode.

in Loaded event:

HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource;
HwndTarget hwndTarget = hwndSource.CompositionTarget;
hwndTarget.RenderMode = RenderMode.SoftwareOnly;

Answer 2

Something to consider when comparing performance between developer and user machines is the time it takes to load the WPF assemblies.

On a dev machine you might already have visual studio running or have previously run other WPF apps and the assemblies should all have been loaded by the time you run your app.

On a user machine, perhaps freshly rebooted, the assemblies will be loaded when the app is started, making startup significantly slower. Depending on how the app is setup there might be additional assemblies loading when various features / pages are used for the first time.

I've found the EQUATEC profiler to be useful in debugging these performance issues. Changing the profiling to "Full usual info" in the app options before building your project will profile down to the binding level.