On Mon, Sep 13, 2010 at 10:13:46PM +0100, Tim Bunce wrote: > On Wed, Sep 08, 2010 at 07:09:05AM -0400, John P. Linderman wrote: > > The summary time on line 1118, 125s, is plausible. > > > > But the times on lines 1128 (433s), 1133 (432s) and 1144 (863s) > > are inconsistent with the summary time on 1118, and inconsistent > > with common sense (could 1144 take 900 times as long as 1143?). > > > > For what it's worth, these oversized times are often > > close to the same (1128 and 1133) or close to even multiples > > (1133 and 1144). I'm still getting useful information from > > the profiler, but these large values are troubling. > > Any insights? -- jpl
I'm pretty sure this is due to the clock going backwards causing a negative tick count. The file i/o code uses unsigned ints so the negative tick count gets translated into a large positive tick count. The file format probably needs to be extended to handle negative values. (I tend to think it's better to let the occasional negative values pass through into the per-statement accumulator, rather than truncate them to zero. I suspect truncation would lead to less overall accuracy.) Meanwhile, the workaround is to use a monotonic clock. Tim. -- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected]
