views:

237

answers:

6

I've always wondered this. I have a habit of always adding

use strict;
use warnings;
use Data::Dumper;

to the top of every script I write. Does this add overhead if I don't even use the Dumper function? Also, in most cases Data::Dumper was called earlier in another package but I need it in this package so I include it again. In this case does it produce additional overhead?

+9  A: 

If they have BEGIN blocks or import routines, then yes, it always adds overhead. Also any mainline code will be executed eventually and any INIT, CHECK, and END blocks will also execute.

The only way it won't add overhead is if the module expects use to be nothing more than like require. (Of course, require also runs everything except the import routine, but that's why I mentioned the view from the use-d module. It "expects" to be nothing but a simple require.)

If you want to retain that line, for some reason, just comment it out. In development, it's okay to have modules that you don't use. In QA or production, that's a mistake, IMO.

Axeman
But development should also mirror production to the extent possible. I'd rather have something like Data::Dumper always included than only included in development.
ysth
Sure, and that's why when you check it out, it should have the "#use Data::Dumper;" in it. Since you're often going to be changing things in development, uncomment the line and you're good to go. If you want it back to how it should work in production, then comment the line out again.
Axeman
+8  A: 

Perl must parse the code in Dumper.pm, so your program will be slower to start up. This is normally a very trivial hit to performance. Also, any code not in functions or in the import function will run. This may have a minor impact on your start up time. You will also consume more memory (the AST for the code and any data structures the code builds). It isn't the best thing you can do, but it is far from the worst. Unless your programs very often (multiple times a minute), you should not notice any real improvement in speed by removing the line.

Chas. Owens
+1  A: 

This can be important if your script is repeatedly executed and there is a latency or run-time constraint.

For instance, if it is a process forked every time a web page is rendered, you probably want to minimise the amount of code that you parse during loading by removing unused modules.

Or if you are running perl on the right hand side of xargs.

There are other ways to remove that overhead in the web server situation.

Alex Brown
+4  A: 

Each use consumes time before your script starts up and likely increases the memory footprint of the script. To test the overhead, you can run the following script:

 C:\Temp> cat zzz.pl
 #!/usr/bin/perl
 sleep 10;

 C:\Temp> timethis zzz.pl
 TimeThis :  Elapsed Time :  00:00:10.172

Memory footprint in Task Manager was 2548K.

Now add

 use Data::Dumper;

and test again:

 TimeThis :  Elapsed Time :  00:00:10.266

This time, the memory footprint was 3408K. So, you waste some time and some memory if the module you use'd is not really used.

The startup time matters in scripts invoked repeatedly (like CGI) and the memory footprint matters, among other cases, in long running scripts and scripts.

Sinan Ünür
+1  A: 

If you ask you don't mind it. Yes, it adds some overhead. Code:

use Data::Dumper;

is almost exact equivalent of:

BEGIN {
  require Data::Dumper;
  Data::Dumper->import();
}

It means, that in compile time Data::Dumper module is parsed and body executed unless it haven't done yet. It means that if you have many modules and use Data::Dumper in each this overhead is happen only once. Check for already done require is very fast, really very fast. Second line does import call and it installs imports to current package name-space (obtained by caller). It takes some time in all modules where used. If you want avoid it use:

use Data::Dumper ();

Than you can't call Dumper() but you must use Data::Dumper::Dumper(). I prefer using Data::Dumper->Dump([vars], [names]) which bring me output which I like more.

Hynek -Pichi- Vychodil
A: 

This isn't quite what you asked, but I find relying on Data::Dumper to be a crutch and a habit worth breaking. Since perl follows the philosophy of presuming fellow code is friendly rather than malicious, it is very tempting for the programmer to Data::Dump an opaque object to discover how its internals are stored, and then to access those internals directly, rather than using the provided interfaces. Data::Dumper is one of the reasons why Inside-Out objects were created -- to make it harder/impossible for keen but impatient programmers to be nosing around through internals.

Ether