This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Does self sample tell the performance cost of each line of code in Code view?

Hi,

I am currently profiling performance using streamline, whose version is 7.8.0.

And I've found that there is a self sample column in the `Code` view, both in source code view and disassembly code view like:

What does this mean please? Does this tells the performance of each line of code?

Parents
  • Hi 

    Streamline is a statistical sampling profiler; this means it periodically samples the program counter or call stack, using a fixed frequency timer, and reports the total number of samples associated with an address / line / function / callpath. This measure does not tell you the relative cost of a particular line or instruction, just the frequency with which a particular piece of code is called. Functions / lines / instructions that appear often (have a higher number) are where your program is most often seen and so should be the focus of any optimisation efforts.

    If you are interested in measuring a particular metric such as finding areas of code that cause frequent cache misses, then you may wish to look at using Event Based Sampling (as opposed to time based sampling) which causes Streamline to sample to call stack or program counter every N-many events rather than every N-many nanoseconds. In this case, your functions with the highest number are statistically more likely to trigger that event than those with lower values.

Reply
  • Hi 

    Streamline is a statistical sampling profiler; this means it periodically samples the program counter or call stack, using a fixed frequency timer, and reports the total number of samples associated with an address / line / function / callpath. This measure does not tell you the relative cost of a particular line or instruction, just the frequency with which a particular piece of code is called. Functions / lines / instructions that appear often (have a higher number) are where your program is most often seen and so should be the focus of any optimisation efforts.

    If you are interested in measuring a particular metric such as finding areas of code that cause frequent cache misses, then you may wish to look at using Event Based Sampling (as opposed to time based sampling) which causes Streamline to sample to call stack or program counter every N-many events rather than every N-many nanoseconds. In this case, your functions with the highest number are statistically more likely to trigger that event than those with lower values.

Children
No data