1

I'm pretty new to profiling so I don't know how to even approach this issue. Basically, I want to discover why some hiccups in the UI are occurring. Profiler seems to be made for solving these kinds of issues so I went with that. I'm using Visual Studio 2010 on a Windows 8 machine so my only option is instrumentation profiling.

Unfortunately, what I get is a bunch of distracting hot paths that occur because of MessageBox.Show calls and long-running threads waiting for data with Monitor.Wait. These methods, of course, take orders of magnitude longer than the issues I'm trying to understand.

Is there no way to somehow filter-out these long-running methods? Ideally by function name or some other criteria, perhaps elapsed exclusive time.

relatively_random
  • 4,505
  • 1
  • 26
  • 48

2 Answers2

1

Profiling is not for UI. Profiling is for calculations and other logic. If you really need to profile UI (which you should not) you can hide message boxes and simulate button clicks. Something like:

#if PROFILE_VERSION
    DialogResult result = DialogResult.OK;
#else
    DialogResult result = MessageBox.Show();
#endif

Of course you'll need to define PROFILE_VERSION and create new configuration for this.

But really, you should only test your logic.

Adam Jachocki
  • 1,897
  • 1
  • 12
  • 28
  • Then which tools are meant for analysing performance issues tied to the UI? The only alternative I see is exporting the call tree and writing a custom display tool that can ignore certain methods or subtrees. – relatively_random Apr 21 '17 at 11:33
  • 1
    Why would you profile UI anyway? What is your exact problem? – Adam Jachocki Apr 21 '17 at 11:37
  • I'd like to figure out what is taking the most time when dynamically layouting the UI in an application. The same as any other performance issue: something is slow and I'd like to know what to see if it can be helped. – relatively_random Apr 21 '17 at 11:46
  • I'm afraid that you have mixed UI with logic. Logic in this case is dynamic creation of UI. UI in this case are things like MessageBox. This is bad architecture. If UI is created dependent on user input, then you should take all input first and then create UI. – Adam Jachocki Apr 21 '17 at 12:33
0

Aside from hot paths being some of the pointless information profilers give you, here is how I would approach finding your "hiccups".

Most of the time I use random pausing. I try to collect samples during the slow times (the "hiccups") so I can see what it's doing in that time. If I get samples that I can see are not relevant, I just ignore those.

If the hiccups happen too fast to do that, there's a more difficult method. It requires setting a few-millisecond timer interrupt with a handler. When the suspect code starts, it enables the timer, and when it finishes it disables the timer. That way, if it takes longer than normal to finish, the timer goes off. If I set a breakpoint in the handler, I can look to see what the program was doing when the timer went off. That's a way to get a sample. If I get several samples, that's usually enough to show the problem.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • Random pausing just shows MessageBox.Show and Monitor.Wait intentional waits. How to get the pause of random to hit when there is no active messagebox / monitor waiting? – osgx May 31 '17 at 18:42
  • @osgx:If the program spends nearly all its time waiting for user input, what can you do? 1) You can decide it's not a problem. 2) You can wrap a loop around the actual computation to make it take a lot more time, tune it, then remove the loop. 3) Do something with a timer interrupt, but that's more trouble. – Mike Dunlavey May 31 '17 at 23:40