.netwpfperformanceantsgetmessage

Why would GetMessageW take up massive CPU usage in my WPF application?

I've got a serious head-scratcher on my hands here. I'm investigating performance issues with a WPF component in our application.

Our .net application is very large, and almost entirely in windows forms. As part of a new initiative we rewrote one of our core components with a rich WPF ui. There is a lot of WinForms<-->WPF interop going on with this thing to glue it together, and I suspect that may be somehow related to what I'm seeing.

When I profile the slow operation in ANTS profiler, I see a lot of activity occurring inside the function UnsafeNativeMethods.IntGetMessageW. ANTS reports as much CPU activity going there as it does to all of our business logic and wpf rendering stuff combined. There is no managed code downline of that function that is using the cycles, so whatever IntGetMessageW is doing there is what I'm after.

I'm not particularly well-versed in win32 programming, but I know the basics of a message loop in that context. None of what I'm seeing here though is anything we do manually -- at no point in our code are we interacting directly with either the underlying messageloop itself, or any of the more complicated stuff that can be accessed on the WPF dispatcher.

Our WPF component in question here is written inheriting from Window (ie. it's not just a control/usercontrol), and we show it using ShowDialog out of our higher level logic that used to call ShowDialog on the old WinForms version of this component. There are some WindowsFormsIntegrationHost controls that we have used inside of the WPF component to preserve compatibility with some of our existing pieces that could not be rewritten in WPF.

I've been researching this for days, but have never found a whole lot to go on. I keep finding vaguely related postings that talk about input messages (mouse and keyboard), but I don't know what I can do to verify that; I've already tried butchering the code to remove every mouse/keyboard operation I could.

I'm having a hard time getting anywhere primarily because this line of code is completely isolated (not a parent or child of anything I can point out as actually coming from our code), and completely opaque about what it is doing.

Here is an image of an ANTS call graph of the ShowDialog function showing the path of calls to get here: alt text

I fully realize that this could be something that just has to be done as part of WPF (although other componenets we have written in WPF don't display this behavior), or that this is just a very strange bug in ANTS profiler, but at this point I need to verify it one way or another. If anyone can tell me what is or might be going on here -- or point me to some way I would be able to figure it out myself, I will direct all kinds of good karma your way.

UPDATE: In response to some discussion below, here is another view from ANTS -- this one better illustrates the confusion I am having (this is with the ANTS view in "CPU time" mode). I've hastily censored parts of our code, but none of the system related functions:

alt text

Thanks for looking!

Solution

  • I found this while searching for information on the same issue. I'll add what I know and see if it helps:

    I'm running on a WinXP box - the WPF framework is more integrated in Vista and Win7 than it is in XP. Some of this could be due to how WPF runs "on top" of the XP desktop, rather than within it.

    I'm running a pure native WPF application - with no WinForms or other code.

    I ran into this trying to determine why simply scrolling a window would consume 100% CPU and stutter while doing it.

    Running the AQtime performance profiler, I see that IntGetMessageW occupies the largest part of that 100% CPU usage. This is not due to IntGetMessageW waiting for a message, but something the function is actually doing.

    The one thing I haven't looked into yet is that maybe IntGetMessageW has never been a fast method, and maybe WPF simply overuses it. It is possible that data bindings in WPF use the native Win32 message pump to update Dependency Properties within WPF. If that is the case, it could be that my window simply has too many bindings.