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

Question

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,

Answer 1

When profiling an application, you need to differentiate between time spent in a method and CPU cycles consumed. Many profiling tools show you the overall time spent in a method - which in the case of somthing like GetMessageW is going to be quite high. All of the activity of the main thread of a GUI application will appear to happen within that method. That's not necessarily a problem, however ... this may simply be the main message pump waiting on a synchronization objects and not actually consuming cycles.

I would suggest you start by using the sampling feature in the ANTS profiler to identify the methods that are called most often and correlate those to the methods that are consuming the most CPU cycles. Once you've done that, you decide where to instrument your application to dive in further and get an idea of what the call graphs look like for the places that are most CPU intensive.

You should start by suspecting your own code first. It's rare that something like the WPF or Win32 infrastructure is responsible for poor performance or high CPU utilization. Likely, the problem lies somewhere in your implementation - it helps you get an overall sense of where CPU cycles are spent in your program.

I suggest that you also spend some time learning the capabilities of the profiler to be most effective. Profilers can be sophisticated and confusing tools until you understand what it is that they are trying to show you. The linked tutoral from RedGate should be a good place to start, if you haven't done so already. For example, the Timeline view may actually be a good place to start to see where high-CPU activity is occurring, and confining your analysis to those segments of executed code.

The Call Graph is another useful tool in ANTS, as it helps you drill into areas of the code that are most expensive. The key is to make sure you are looking at the overall cost and not just the overall time.

Answer 2

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.

Answer 3

Yes, this is normal. Any GUI app is always executing GetMessageW(), waiting for Windows to send it a message. It isn't actually burning CPU cycles doing this, just blocked on an internal synchronization object until some kind of UI event is signaled.

This of course makes profiling UI apps difficult, you really need unit tests that test the subcomponents of your app.

Answer 4

Looks like your message pump is pumping a lot. Could be interesting to see what kind of message your message queue is filled of. Can you use Spy++ on your window to see what is going on?

Edit

I've misunderstood the problem.

Hans Passant is right, your program is just waiting on GetMessage for some event to process.