Re: Devel::NYTProf and Devel::Cover overlap and cross-polination

On 21 Jul, 16:13, Tim.Bu...@pobox.com (Tim Bunce) wrote:
> On Thu, Jul 17, 2008 at 11:49:06AM +0200, Paul Johnson wrote:
> > On Wed, Jul 16, 2008 at 03:00:06PM -0700, Tim Bunce wrote:
> > > On Thu, May 03, 2007 at 12:56:44AM +0100, Tim Bunce wrote:
> > > > I'm not very familar with this part of perl guts...
>
> > > > How can I find the line number of the start of the current block/scope?
> > > > Or, more likely, the line number of the first statement in the block/scope?
>
> > > I got there in the end:
>
> > >    http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-per...
>
> > Hi Tim,
>
> > I've not had the chance to try the module, but based on what you have
> > written, do you think there might be any chance of somehow merging the
> > backends of Nytprof and Devel::Cover?
>
> I don't see much benefit at first sight. Profiling and coverage analysis
> use similar technology (and may benefit from cross-pollination of
> implementation ideas) but they're very different user activities.
>
> Please excuse the tersness of my responses below.
> They simply reflect an "I don't get it" point of view.
>
> > (The corporate firewall took
> > exception to your blog, so I've only seen it via links.)
>
> Any idea why? (Perhaps reply offline. I could email a copy if you'd like.)
>
> > As you know, Devel::Cover has something of a statement level profiler
> > included, and Nytprof output is based on that of Devel::Cover.
>
> The visual style is similar but the coode looks quite different.
>
> > It would be great to be able to replace Devel::Cover's basic statement
> > level profiler with Nytprof and combine the output.
>
> Why?
>
> > This would also
> > give Nytprof access to the other reports in Devel::Cover.
>
> Such as?
>
> > This could either be done at the level of the Devel::Cover database,
> > or using the annotation facility available to Devel::Cover reports.
>
> > Does this seem worth pursuing?
>
> Not at first sight, but perhaps I'm just being dense and missing something.
> Feel free to persuade me!
>
> Tim.

Paul,

Data pertaining to what lines are hit during execution are definitely
maintained by the nytprof database, so coverage reporting is
definitely possible.

The bin/nytprofhtml script is where the "untouched" lines of code are
added into the mix.  That script just prints out all the lines of code
it finds and tacks on some profile data (if found).  You could
definitely use nytprofhtml as a jumping point into code coverage --
say bin/nytprofcover.  The output generation scripts in the bin/
directory use the NYTProf::* modules as their data source, so you
don't even need to open our XS.

The nytprof.out database is overkill when used as a coverage
information source.  That said, if it can be done entirely in an
encapsulated output script, I don't see why it would be a problem.

-Adam

• Devel::NYTProf and Devel::Cover overlap and cross-polination by Tim Bunce
• Re: Devel::NYTProf and Devel::Cover overlap and cross-polination by Adam Kaplan
• Re: Devel::NYTProf and Devel::Cover overlap and cross-polination by Tim Bunce