[Mastering-perl] Debugging, Profiling, and Cleaning Up Code

[Adrian Howard]

On 11 Oct 2006, at 19:28, brian d foy wrote:

> On 10/11/06, Adrian Howard <adrianh at quietstars.com> wrote:
>> On 7 Oct 2006, at 11:46, brian d foy wrote:
>> [snip]
>> > I've added a bunch of stuff to the Debugging chapter:
>> >
>> > http://www.pair.com/~comdog/mastering_perl/Chapters/ 
>> 04.debugger.html
>
>> I kinda expected the print/warn section to move on to a discussion of
>> logging modules, does that happen elsewhere?
>
> Logging is different than debugging. :)

Different, but related.

Looking at what the print statements / logging information says and  
figuring out how that indicates a problem in the code and then fixing  
it... that's debugging :-)

If you have a logging infrastructure why not use it? Especially if it  
makes adding information useful for debugging easier that print  
statements in some contexts.

> I think there is going to be a logging chapter. I just haven't gotten
> that far yet.

I think a logging chapter would be most useful - with a pointer from  
the debugging chapter :)

This may just be me, but I tend to view my having to throw print  
statements into code to understand a bug as a sign that one or more  
of the following is true:
* the design of this code sucks
* the code has lousy tests
* the code has a lousy logging system

Obviously, fixing the bug is the prime objective. However fixing  
those other things comes a close second for me.

>> I'd stick in a warning about the problems with $SIG{ __DIE__ } and
>> $SIG{ __WARN__ } and persistent environments like mod_perl.
>
> I'm talking more about those in the chapter I'm working on now (the
> Error Handling chapter), so I'll probably punt from the debugging
> chapter to that chapter. Basically, don't do those things as a code
> feature. It's a tool for diagnosis when you need a hook into the code
> to figure out what's going on.

I agree completely. The thing you have to be careful about is when  
that persistent code has some SIG handlers that it needs to run  
successfully, so adding the diagnostic ones can sometimes cause  
random breakage elsewhere. Huge PITA.

[snip]
>> POD coverage modules?
>
> I think  I got those in the pod chapter. I don't really count that as
> part of Profiling though.

Fair enough.

>> Memory profiling? - Devel::Size, Devel::Size::Report,  
>> Devel::DumpSizes ?
>
> See the Benchmarking chapter for that stuff.

Maybe a pointer across then?

> Note, however, that
> currently Devel::Size is broken, so I'm not so keen about talking
> about it too much. :)

Fair enough.

> Does anyone have tools, tricks, or tips for doing memory profiling  
> on Windows?

Not here... sorry.

Adrian