7

My WPF application has a feature whereby it renders a large number of images in the background while updating the UI whenever a new image is ready.

Profiling this process has shown that Application.Run is the function doing the most work, at 43%, with the "second most expensive" spot shared by three graphics APIs, each at 6%.

What might I be doing that would cause so much time to be spent in Application.Run? It seems that the core of this method is running the main dispatcher for my app, but that doesn't help me figure out what it is that the dispatcher is doing so much. Can I get a more fine-grained profile?

Note: I mean System.Windows.Application.Run.

Roman Starkov
  • 59,298
  • 38
  • 251
  • 324

1 Answers1

4

Turns out that the Visual Profiler (part of the WPF Performance Suite) can provide a more detailed break-down of the CPU usage:

CPU usage breakdown

This shows that half of that unexplained CPU usage is down to the rendering thread (so perhaps I should update the UI less frequently), and much of the rest is spent in my Invoke callback (which is unavoidable in my case).

Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • Right. Think of a program as a circus unicyclist furiously pedaling to balance a tall stack of acrobats, each telling him which way to go. He's not the problem, the problem is higher up. You could get the same information by means of a few *[stackshots](http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024)* of the threads, and it would tell you exactly which lines of code were the culprits. – Mike Dunlavey Feb 02 '12 at 19:21