SPUG: Debugging methodology (was: How to deal with same name packages?)

[Richard Anderson]

There are dozens (hundred?) of tools for profiling/benchmarking code, some
commercial, some open source, some bundled with the particular
compiler/interpreter you are using.  For Perl, look at these modules:

Profiler
Devel::DProf

These may also be of interest:
Time::HiRes
Benchmark and its subclasses

Richard Anderson
206.547.6903
richard at richard-anderson.org
www.richard-anderson.org
----- Original Message -----
From: "Brian Maddux" <brianmaddux at yahoo.com>
To: "Richard Anderson" <richard at richard-anderson.org>; <spug-list at pm.org>
Sent: Tuesday, January 15, 2002 9:30 AM
Subject: Re: SPUG: Debugging methodology (was: How to deal with same name
packages?)


> You mention "you have profiled the code". Are there
> tools for doing this? I do the other 2 tasks, but not
> this one....
>
>
> Thanks,
> Brian
>
> --- Richard Anderson <richard at richard-anderson.org>
> wrote:
> > The performance hit is negligible, especially when
> > you compare the
> > millisecond lost per run to the minutes, hours or
> > days of human time lost to
> > debugging or incorrect results.  The advantage of
> > having a variable is that
> > the user of the module can activate debugging at run
> > time without modifying
> > the source code.  In many cases the user of the
> > module will not be able to
> > modify the module source code without getting
> > administrative privileges.  In
> > large organizations it is simply not feasible for a
> > maintenance programmer
> > to modify production code while debugging because
> > the bits have been stamped
> > as tested by the test group and installed by the
> > release group.
> >
> > To repeat what all the books say about optimization:
> > don't twiddle code to
> > optimize until (1) you have working, debugged code,
> > (2) you have profiled
> > the code, and (3) you have optimized the algorithms
> > and data structures
> > underlying the code.  Minor gains in performance at
> > the expensive of code
> > flexibility or readability are not cost-effective.
> > Bugs are extremely
> > expensive to fix; computer time on the order of
> > milliseconds is cheap by
> > comparison.
> >
> > Richard Anderson
> > 206.547.6903
> > richard at richard-anderson.org
> > www.richard-anderson.org
> > ----- Original Message -----
> > From: "Chris Wilkes" <cwilkes-spug at ladro.com>
> > To: <spug-list at pm.org>
> > Sent: Tuesday, January 15, 2002 12:46 AM
> > Subject: Re: SPUG: Debugging methodology (was: How
> > to deal with same name
> > packages?)
> >
> >
> > > On Mon, Jan 14, 2002 at 10:08:53PM -0800, Richard
> > Anderson wrote:
> > > >
> > > > Callers of my modules can activate debug
> > messages using a class variable
> > > > Debug:
> > > >
> > > > use MyClass;
> > > > $MyClass::Debug = 1;         # or 2 or 3
> > > > $MyClass::DoSomething();
> > > >
> > > > and in MyClass:
> > > >
> > > > if (Debug > 0) {
> > > >    print (whatever)
> > > > }
> > > >
> > > > I usually have two or three debug levels of
> > varying verbosity.  The
> > debug
> > > > messages are written to standard out or the
> > Apache error log for
> > mod_perl
> > > > apps.   The performance impact of checking
> > $Debug is trivial compared to
> > the
> > > > benefits.
> > >
> > > If you made Debug a constant then there wouldn't
> > be a performance hit as
> > > it would get optimized away at run/compile time,
> > if my memory of a
> > > recent TPJ article by Sean Burke is correct.
> > >
> > > With DEBUG => 3 then you'll have "If (3 > 0) {
> > print }" which will get
> > > optimized to just "print"  Likewise if you had
> > DEBUG => 0 the whole "if
> > > ( 0 > 0 ) {}" will get thrown out.
> > >
> > > Chris
> > >
> > >  - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - - - -
> > >      POST TO: spug-list at pm.org       PROBLEMS:
> > owner-spug-list at pm.org
> > >       Subscriptions; Email to majordomo at pm.org:
> > ACTION  LIST  EMAIL
> > >   Replace ACTION by subscribe or unsubscribe,
> > EMAIL by your Email-address
> > >  For daily traffic, use spug-list for LIST ;  for
> > weekly, spug-list-digest
> > >      Seattle Perl Users Group (SPUG) Home Page:
> > http://zipcon.net/spug/
> > >
> > >
> > >
> >
> >
> >  - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - - -
> >      POST TO: spug-list at pm.org       PROBLEMS:
> > owner-spug-list at pm.org
> >       Subscriptions; Email to majordomo at pm.org:
> > ACTION  LIST  EMAIL
> >   Replace ACTION by subscribe or unsubscribe, EMAIL
> > by your Email-address
> >  For daily traffic, use spug-list for LIST ;  for
> > weekly, spug-list-digest
> >      Seattle Perl Users Group (SPUG) Home Page:
> > http://zipcon.net/spug/
> >
> >
>
>
> =====
> Brian Maddux                    Whidbey Island, WA
> brianmaddux at yahoo.com
> http://www.geocities.com/SiliconValley/5308
>
> ** Please DO NOT mail to brian_maddux at bigfoot.com. **
> ** That address WILL NOT WORK starting sometime in **
> ** August 2001. Thanks.                            **
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
>


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/