We Keep Coding

WPF C# Application Performance

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!

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;

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.

WPF Application Slow Unresponsive when demonstrating using remote sharing software

After spending 14 hours on this I think its time to share my woes and see if anyone has experienced this issue before.
Ill describe the issue and tests I have done to rule out certain things.
Ok so I have a WPF application which loads in data from an SQL database.
I am using DevExpress Components for datagrids, ribbons etc.. and FluentNhibernate to provide a session for database operations. I am also using log4net to log events to a textfile.
Using the application on my laptop with SQL Express 2008 works fine.. the application starts up, retrieves 1000 records and I can tab through the controls on the ribbon.
Now, I decided to demo the application to a third party and used remote login/sharing software online to share my desktop with the other person so as I could load the application on my laptop and they could view me using the application.
Now, the application takes approx 45 seconds to load... 30 seconds with a blank database where as, when im not sharing out my screen using the online software the application loads in about 7-10 seconds. As well as that, even using the controls in the application during the demo were very sticky, slow and unresponsive.
During the sharing session though however I was able to use other applications without any problems.. everything else worked fine.
But I cannot understand how my application works ok under normal conditions , even browsing the net at the same time etc... BUT totally fails to perform correctly when I am sharing a session with another user... the CPU usage shot up to 100% too at times when the application was trying to start up...
Please see below a list of 3rd party dlls I am using as references in my project.
DevExpress dlls
FluidKit
PixelLab.WPF
PixelLab.Common
Galasoft WPF Kit
FluentNHibernate
NHibernate
Nhibernate.ByteCode.Castle
Skype4ComLib
TXTEXTControl
log4net
LinqKit
All of these DLLs are in the output folder with the application dlls created from the class assemblys in the project. So when installed via an installer on a machine the dlls will be in the same application folder as the application file itself.
Many thanks

I saw something similar about a year ago with logmein. The performance is not the app its the graphics processing . WPF renders graphically in a completely different way then GDI winforms see around 2.3 and down msdn article. Many remote desktop application have trouble rendering this correctly particularly if you don't use the plug ins (say logmein). You didn't say what you were using but I would suggest trying a few different RDP options as there are many out there, and making sure your on the newest versions.

Yes, as bumle-bee-tuna points out, WPF will default to software rendering over Remote Desktop. Another way may be to screen share using Skype or similar. This means you'll be rendering the app locally but transmitting an image to the remote user. the app should work at full speed and the only lag the viewer will see will be introduced by the Skype network. I've used this technique many times to deliver presentations remotely and works well!

c# application working on development machine, fails on non-development machine

this problem has me baffled.
I'm writing an application which is supposed to take information from a form, pass it to a background worker which then a) writes the information to a local xml file and b) inserts the information into a remote MySQL database.
On my development machine, it seems to work flawlessly. The remote database is updated, the xml file is created if necessary and updated if it already exists. It's working.
Even if I exit out of the development environment and run the release build independantly of the IDE sandbox, the code works.
But, if I put it on another machine, the code fails and I dont understand why.
I'm currently using Visual Studio 2010 Professional on a 32 bit Windows 7 Ultimate machine.
At the moment, I'm finding that the application is stopping at a fairly specific point, which seems to be precisely where the background worker starts doing things like accessing the file system or accessing the remote database.
The project consists of a single exe file and a dll, which has a custom control I designed in it. The custom control is working fine, in that it shows what I want it to and returns the values I'm asking it to when I want it to, so it would seem that isn't to blame.
I initially thought I could be looking at a permissions problem, but running the application as administrator gets me the same response.
I've been writing using version 4 of the .NET framework, however I've just downgraded that to version 3.5 in the hopes that that may help. Both the non-development machines I've tried have been up to date - or have been brought up to date by me - prior to attempting to run the application.
I'm honestly baffled here. Any suggestions would be most welcome.
Alan

If your code fails, it most likely means there is some uncaught exception. What you should do is to log all uncaught exceptions (and probably some of the caught too) to a file, possibly using something like log4net.
I don't think we can help you beyond that.

I have written a live logging utility called Donsole for diagnosing the application in such conditions. On the developer workstation, it is very easy to diagnose using the feature-rich debugger of VS. The utility app. helps the developers exactly in this kind of scenarios where they don't have any idea what's happening inside. I recommend you download the latest build and try it for yourself. Explaining how to use this utility and how it works is beyond the scope of this answer, so I'd forward you to the codeplex page of the project.
http://donsole.codeplex.com/
This is how it looks.

Take a look at the event viewer of your operating system. Administrative Tools>Event Viewer>Windows Log>Application.

.Net Application extrem slow. After killing svchost.exe it runs again fast. Any idea?

I've a C# .Net 3.5 Application (x86) running on Windows7 x64.
For any reason after a few days or weeks the App runs extremly slow.
All other Apps runs normal (also another C# .Net 3.5 Application (x86)).
After killing a few svchost.exe the Application runs normal again. Rebooting without killing svchost.exe also doesn't help. Probably Windows saves the state of svchost.exe. If I logoff the user and login again it also works again, without killing the svchost. On logoff the svchost is probably cleared.
Does anybody have an idea how to solve the problem?
Greets
Wowa
EDIT:
The Main-Form is just an MDI-Container with a Treeview on the left-side with static nodes.
The Application checks on start for Updates via networkpath (checks files creationdate), but this can't be the problem, because all other PC works without a problem.
After the Update every MDI-child-form takes 1-2 minutes to start, even a empty form.
EDIT:
Sorry, i've forgot, that the updating is no more done by this application, but by another, which has nothing to do with the app which runs slow.
The app which updates the slow app runs normal. It only updates the slow app if it isn't running.
But the slow App removes files in the local Temp-path. System.IO.File.Delete()

Without any details or code as to how exactly your application checks for updates at startup, I'm going to guess that it's doing it on the UI thread (main thread), and blocking your application while doing it.
You mentioned that it's checking for updates via networkpath, I'm going to assume that you mean network share, in which case this might be the reason one of the svchost processes is acting up. Get Process Explorer, and use it to determine exactly which services are started by the offending svchost (by looking at the hint, or the Services tab in the process properties):

Perhaps it could be related to virus scanning software. If you have it installed, disable it and try the process again.

Same thing has been weighing us down.
Acrobat InDesign CS5 ME ver. (x86 app)
We have tried and tried again (Win7 64; 2gb; 1gb video card). I have noticed scvhost # 50,000 sitting in Taskmanager; killed it, but comes back. We haven't upgraded yet because of this.
We run the same app on XP-32, and also have some trouble, but that i more likely because of only 128mb video memory (2 P4 chips, 4gb mem).
I have peeked in ProExp but didn't know HOW to look. Thanks for the tip.
Hey, I'm a plain guy, not a pro programmer.

wpf app invisible remotely (via radmin)

I've built a little WPF utility that watches a serialport and visualises monitoring information with WPF. It works fine, but a colleague just tried using it from another machine via radmin and my app is completely invisible! if you're at the machine you see it, if you view it via radmin you see the same screen but no app. Instead you see the app behind it (in this case windows explorer), but can't click on anything in the space where my app is.
Has anyone else come across this before??

It sounds like you need to upgrade to .NET 3.5 SP1.
On .Net Framework 3.5 SP1
We now remote as bitmaps in ALL cases.
The reason is that WPF 3.5 SP1 now
uses a new graphics DLL (wpfgfx.dll)
and certain changes could not be made
to Vista’s existing graphics DLL
(milcore.dll) that is also used by
DWM. Although this could be seen a
regression at first, depending on the
complexity of the application scene
(e.g. very rich scenes) this can
actually improve performance in
certain scenarios . Also, connections
with reasonably high bandwidth and
scenarios that don’t involve a lot of
animation or 3D, for instance, tend to
remote just fine via bitmaps.
Source

Checked the framework and it was already 3.5 SP1.
It's ok via RDP, so my colleague is happy. It just seems to be radmin, which I'd never used before and don't see the need for.