How to read NYTProf html reports?

Question

I'm completely confused about Devel::NYTProf reports generated by nytprofhtml. I'm using old version of NYTProf 1.90. I know it is very old version but should use it for number of reasons.

So these HTML reports look something like this (when looking on particular *.pl file report):

|Line|Stmts.|   Time   |  Avg. |Code|
|42  | 6804 | 0.04506  | 7e-06 | }; |

I have never seen reports from new version of nytprofhtml, so not sure if they look the same.

In, my case this line is most slow part in whole program (it not a small program). So my question is how can statement like this '};' be slowest part in the program with lot more complex statements. I think misunderstand what NYTProf reports.

If my question is confusing just give me definitions of each column from these reports this will help? This will help a lot.

Especially I'm interested what Stmts. mean. I'm guessing, but I don't want to guess!

Thanks in advance.

Answer 1

Stmts. is the number of times the statement was executed or, more precisely, the number of times execution moved from a statement associated with that line (which is not always accurate) to whichever statement was executed next.

Time is the sum of the time spent executing statements associated with that line.

Avg. is simply Time divided by Stmts.

These extracts from the current Devel::NYTProf documentation may help:

The statement profiler measures the time between entering one perl statement and entering the next. Whenever execution reaches a new statement, the time since entering the previous statement is calculated and added to the time associated with the line of the source file that the previous statement starts on. [...]

For example, given:

while (<>) {
    ...
    1;
}

After the first time around the loop, any further time spent evaluating the condition (waiting for input in this example) would be recorded as having been spent on the last statement executed in the loop.

More recent versions of NYTProf, of which there are many, offer much more accurate timings for this situation by intercepting the appropriate internal loop opcodes, plus many other significant improvements.