0

I'm struggling a little with reading the textual output the GPerfTools generate. I think part of the problem is that I don't fully understand how the sampling method operates.

From Wikipedia I gather that profilers based on sample functions usually work by sending an interrupt to the OS and querying the program's current instruction pointer. Now my knowledge about assembly is a little rusty, so I'm wondering what it means if the instruction pointer points to method m at any given time? I.e. does it mean that the function is about to be called or does it mean it's currently executed, or both?

There's a difference if I'm not mistaken, because in the first case the sample count (i.e. times m is seen while taking a sample) translates to the absolute call count of m, while in the latter case it simply translates to times seen, i.e. a mere indication of relative time spent in this method.

Can someone clarify?

osgx
  • 90,338
  • 53
  • 357
  • 513
mxk
  • 43,056
  • 28
  • 105
  • 132
  • Profilers have come a long way from just program-counter sampling, as in [*gprof*](http://stackoverflow.com/a/1779343/23771). Trying to get useful information by sampling the program counter is like trying to tell time on a clock with only a second hand. – Mike Dunlavey Sep 18 '12 at 17:48
  • Isn't that just a question of sample frequency? If I sample often enough, it can be very accurate no? The Wikipedia article also mentions other benefits you get by trading in some accuracy, such as the non-intrusiveness and minimal performance impact of the approach. It furthermore mentions that it can even be beneficial to not be overly accurate, e.g. to "filter out" methods that execute so quickly that they fall through the measurement grid (and hence are not important.) – mxk Sep 18 '12 at 21:07
  • I have problems with that Wikipedia article, as with generally accepted attitudes about performance tuning. People completely lose sight of the purpose. The link I gave you above summarizes it in layman terms, but [*this link*](http://scicomp.stackexchange.com/a/2719/1262) puts it in more mathy terms. The central issue is *false negatives* - the (often huge) speedup opportunities that go undetected, while people go fussing about accuracy and performance impact, which are completely irrelevant. – Mike Dunlavey Sep 19 '12 at 01:36
  • One thing I don't understand about your chain of arguments (don't mean to imply you're wrong here, just that I don't follow) is that you say the *where* is not important. I think it's important, since if the profiler doesn't tell you where to even start looking, how would you optimize to begin with. For example, we're currently migrating our web app to a new version of the platform, and suddenly the average call time (for a request to traverse the stack) doubled. A single call stack is so big, however, that it's practically impossible to find the cause just by looking at it in a debugger. – mxk Sep 19 '12 at 09:07
  • Moreover, what you describe here: http://stackoverflow.com/questions/406760/whats-your-most-controversial-programming-opinion/1562802#1562802 isn't that exactly what a statistical profiler does? Take samples? Maybe I'm missing your point. – mxk Sep 19 '12 at 09:12
  • Taking samples is only half the job. Learning something from them is the other half. Sure I see stack samples 30 levels deep. People look at those and say "what good is that?" when in fact it's a treasure trove, because you can look through a sample carefully and completely understand what's happening. If there's something you can fix, it will appear on more than one of those - simple as that, and just numbers may well not show it to you because they don't expose the faulty reason the time is being spent. On top of that, data is important, which is not caught in timing routines. – Mike Dunlavey Sep 19 '12 at 11:56

0 Answers0