[Melbourne-pm] NYTProf

Paul Fenwick pjf at perltraining.com.au
Tue Feb 10 13:57:11 PST 2009


G'day from Wellington Airport,

Dan Tyrrell wrote:

> Further to the recent talk (in part) on NYTProf by PauI I noticed that
> for certain workloads NYTProf can add significant overheads. See

All profilers add quite a bit of overhead, since they need to interrupt your
program flow to record timing information.  With the default NYTProf
configuration, this happens after every statement, or sometimes multiple
times per statement if you're calling lots of subroutines.

There's a few tricks you can use to speed up profiling, if you're happy to
use information.  For example, one can set an environment variable to tell
NYTProf when it should start:

	export NYTPROF=start=init

to only start after your program has compiled, which can avoid some of the
overhead associated with module setup (which you may not care to profile).
It's even possible to:

	export NYTPROF=start=no

To tell NYTProf not to start at all.  This is handy because you can manually
enable/disable it:

	DB::enable_profile()

	# Code that I wish to profile

	DB::disable_profile()

This is especially useful if you know that a a region of your program is
causing slowdowns (possibly you did profiling previously), and you just want
to gain insights into how that part has improved.

It's also possible to disable line, block, and subroutine profiling, which
will also give you a performance gain.  See the Devel::NYTProf documentation
on the NYTPROF environment variable for details.

Profilers aren't something you want to 'leave on' in your code, because of
the resource requirements.  However compared to the overheads of other
profilers, I've actually found NYTProf to be relatively snappy.

Cheerio,

	Paul

-- 
Paul Fenwick <pjf at perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681


More information about the Melbourne-pm mailing list