Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The second method is essentially stack sampling. You can try to do it yourself, by means of some kind of entry-exit event capture, or it's better if there is a utility to actually read the stack. The latter has an advantage in that you get line-of-code resolution, rather than just method-level.</p> <p>There's something that a lot of people don't get about this, which is that <em>precision of timing measurement is far less important than precision of problem identification</em>.</p> <p>It is important to take samples even during I/O or other blocking, so you are not blind to needless I/O. If you are worried that competition with other processes could inflate the time, don't be, because what really matters is not absolute time measurements, but percentages. For example, if one line of code is on the stack 50% of the wall-clock time, and thus responsible for that much, getting rid of it would double the speed of the app, regardless of whatever else is going on.</p> <p>Profiling is about more than just getting samples. Often people are pretty casual about what they do with them, but that's where the money is. First, inclusive time is the fraction of time a method or line of code is on the stack. Forget "self" time - it's included in inclusive time. Forget invocation counting - its relation to inclusive percent is, at best, very indirect. If you are summarizing, the best way to do it is to have a "butterfly view" whose focus is on a single line of code. To its left and right are the lines of code appearing immediately above it and below it on the stack samples. Next to each line of code is a percent - the percent of stack samples containing that line of code. (And don't worry about recursion. It's simply not an issue.)</p> <p>Even better than any kind of summary is to just let the user see a small random selection of the stack samples themselves. That way, the user can get the whole picture of why each snapshot in time was being spent. Any avoidable activity appearing on <em>more than one sample</em> is a chance for some serious speedup, guaranteed. People often think "Well, that could just be a fluke, not a real bottleneck". Not so. Fixing it will pay off, maybe a little, maybe a lot, but on average - significant. People should not be ruled by risk-aversion.</p> <p><a href="https://scicomp.stackexchange.com/a/2719/1262"><em>More on all that.</em></a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload