views:

55

answers:

3

Hi All

I am working on a rather large .NET WPF real-time application. The application is working great and as expected, except for one BIG issue - UI Update is slow.

This application is highly event driven, there are events raised all over for all sorts of things - through these events the UI is updated.

One or many of these events is blocking the UI from displaying immediately. When all the work is complete, the UI shows the expected results.

Is there any way of determining which event handler is causing the bottleneck?

Any help would be appreciated.

+4  A: 

Do you have access to a code profiler? This is the type of thing they are good at. I recommend obtaining one if the answer is no.

Besides using a profiler. You can do "poor man's" profiling by placing timing statements at the beginning and end of code blocks that you suspect. You can even use a breakpoints and time it with a wall clock. Does the issue happen when you click something? If so start there. Is it a recurring issue without user interaction? Start with timers then.

As for actually solving the problem... Unless the offending handler is doing something that can be made more efficient, consider adopting a multi-threaded approach. The new Task library for .NET 4.0 is really amazing in this regard.

colithium
+1 and a link: http://stackoverflow.com/questions/308816/any-good-free-net-profiler
Heinzi
Hi Colithium. Thanks for responding. The application is multithreaded - making use of Parallelism in my Linq queries and loops. In addition, instead of working with Thread objects i am using the Task.Factory.StartNew for multi-threading. The application contains no timers nor any backgroundworkers. I have a main non-blocking Task (thread) which contains only business logic, i.e. no UI interaction at all. The logic in this task takes certain actions and raises events associated with those actions. I am using VS2010 - which has a profiler. Don't know how to use it and how to assess the results.
c0D3l0g1
+1  A: 

As a first order approxximation, I find it useful to break in the debugger (with the pause button in the IDE), and look at the stack. Do this a few times, and you can see if there is a pattern. Are you always in the same function? Are you doing something expensive in response to an event? Are you getting more events that you expect? It's low tech, but can be very effective.

jdv
+4  A: 

I fully support colithium's suggestion of using a profiler.

In addition, if the blocking takes more than a second, you might be able to hit the "Pause" button in Visual Studio. In the tool bar, there's a dropdown list where you can choose the "Main Thread". Then it jumps to the method which is currently blocking the UI.

Heinzi
Thank You Heinze! Tried your suggestion and it worked wonderfully. Very usefull and simple trick to remember. Believe it or not, it's the application log which was causing the issue. Using log4net appender to update a RichTextBox log UI.
c0D3l0g1
And sometimes, the most simple thing possible works :) +1
colithium