1

Usually profile data is gathered by randomly sampling the stack of the running program to see which function is in execution, over a running period it is possible to be statistically sure which methods/function calls eats most time and need intervention in case of bottlenecks.

However this has to do with overall application/game performance. Sometime happens that there are singular and isolated hiccups in performance that are causing usability troubles anyway (user notice it / introduced lag in some internal mechanism etc). With regular profiling over few seconds of execution is not possible to know which. Even if the hiccup lasts long enough (says 30 ms, which are not enough anyway), to detect some method that is called too often, we will still miss to see execution of many other methods that are just "skipped" because of the random sampling.

So are there any tecniques to profile hiccups in order to keep framerate more stable after fixing those kind of "rare bottlenecks"? I'm assuming usage of languages like C# or C++.

CoffeDeveloper
  • 7,961
  • 3
  • 35
  • 69

1 Answers1

2

This has been answered before, but I can't find it, so here goes...

The problem is that the DrawFrame routine sometimes takes too long. Suppose it normally takes less than 1000/30 = 33ms, but once in a while it takes longer than 33ms.

At the beginning of DrawFrame, set a timer interrupt that will expire after, say, 40ms. Then at the end of DrawFrame, disable the interrupt. So if it triggers, you know DrawFrame is taking an unusually long time.

Put a breakpoint in the interrupt handler, and when it gets there, examine the stack. Chances are pretty good that you have caught it in the process of doing the costly thing. That's a variation on random pausing.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • assuming the time consuming event starts to happens after 33 ms .. ehm after 40 ms.. – CoffeDeveloper Nov 30 '16 at 18:40
  • @DarioOO: Not that it starts to happen after 40 ms, but that it's still happening after 40 ms. – Mike Dunlavey Nov 30 '16 at 18:41
  • We could had a delay because something that usually happens betwenn 1-3 ms lasted from 1 to 30 ms (at the beginnin of the frame). We would totally miss that with that method.(so there are events impossible to catch with a 33 ms interrupt. – CoffeDeveloper Nov 30 '16 at 18:42
  • 1
    @DarioOO: That why "chances are pretty good". A clever program could figure out how to hide from you :) Just do one interrupt, and try it with different delays. – Mike Dunlavey Nov 30 '16 at 18:44