Profilers Instrumenting Vs Sampling

て烟熏妆下的殇ゞ 提交于 2019-12-03 12:23:45

The interrupts generated by a sampling profiler generally add an insignficant amount of time to the total execution time, unless you have a very short sampling interval (e.g. < 1 ms).

With instrumented profiling there can be a large overhead, e.g. on small leaf functions that get called many times, as the calls to the instrumentation library can be significant compared to the execution time of the function.

Mike Dunlavey

It depends how conventional you want to be.

gprof does both those things you've mentioned. Here are some comments on that.

There is a school of thought that says profiling is about measuring. Measuring what? Well, anything - just measuring. Along with this goes the idea that what you want to get is a "big picture" of what's happening. This school looks mostly at trying to find "slow functions", without clearly defining what that even means, and telling you to look there to optimize.

Another school says that you are really debugging. You want to precisely locate bugs of a certain kind - ones that don't make the program incorrect, rather they take too long. These are not big-picture things. They are very precise points in the code where something is happening that costs a lot more time than necessary. Exactly how much more is not important. What's important is that it is located so it can be fixed. In this viewpoint, profiling overhead is irrelevant, and so is accuracy of measurement. What measuring is for is seeing how much time was saved.

One profiler that, I think, successfully spans both camps, is Zoom, because it samples the call stack, on wall-clock time, and presents, at the line/instruction level, percent of time on the stack. Some other profilers do this also, but most don't.

I'm in the second school, and here's an example of what you can accomplish with it.

Here's a more brief discussion of the issues.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!