Bug 176628

Are there any plans to implement sampling (of the PC and call stack) as a performance analysis technique? That is my favorite method, and I've been doing it manually on all software, large and small, for at least 30 years. Some others have also discovered the method and swear by it, while those who have not cannot imagine that it works.

The basic method is that a number of samples of the call stack are taken during the interval of interest. Then, for each instruction that appears on those stacks, the fraction of stack samples on which it appears is calculated. The instructions are then displayed in descending order by that fraction.

Any such instruction, if it could be removed, would save that fraction of the execution time. Any bottleneck taking significant time will appear in that list.

Pros:
  - Captures cost at the fine-grain instruction level (not function). It is easily summarized to the function level if desired.
  - It is immune to cycles. A cycle appears as a call instruction appearing more than once on a stack sample, but that still only counts as one sample.

Cons:
  - It slows down the program to take the samples. This is only a problem if there is confusion between the ends (executing fewer instructions) and means (finding the unnecessary instructions).
  - It consumes more storage for the samples. Offsetting this is the fact that it is not necessary to achieve high statistical accuracy with a large number of samples. Typically the smallest bottlenecks consume 5% of execution cycles, and are easily found with 50-100 samples.

For UI presentation, a butterfly view is easy to present, and quickly leads the user to the problem.

I would be interested in helping to implement this, if that is appropriate. I built such a sampler and UI in the early 90s, for DOS programs, but it used a TSR and is way out of date.

Thanks,
Mike Dunlavey

P.S. I also wrote a couple articles